A flaw was found in m17n-lib. An attacker could provide specially crafted or truncated UTF-8 input to trigger an unhandled null pointer dereference during text processing. This issue causes the application to crash unexpectedly, resulting in a Denial of Service (DoS).

A flaw was found in m17n-lib. An invalid UTF-8 sequence containing a lead byte in the 0xFE-0xFF range can cause countutf8chars() (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: CHARUNITSBYHEADUTF8(0xFF) returns 0, so the scanning pointer in countutf8chars() 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.