A flaw was found in m17n-lib. An invalid UTF-8 sequence containing a lead byte in the 0xFE-0xFF range can cause count_utf_8_chars() (src/mtext.c) to make no parsing progress, resulting in an infinite loop and sustained CPU consumption when processing crafted M-text input. Independently reproduced: a crafted .mim database entry containing byte 0xFF causes the plain build to spin at ~100% CPU until killed (confirmed via `time`: ~4.9s of CPU time consumed in a 5s window, process required external termination). Root cause confirmed in src/mtext.c: CHAR_UNITS_BY_HEAD_UTF8(0xFF) returns 0, so the scanning pointer in count_utf_8_chars() never advances. Upstream maintainer Kenichi Handa reviewed the report and confirmed the affected byte range is 0xFE-0xFF rather than the broader 0xFC-0xFF range originally suggested by the reporter.