A flaw was found in m17n-lib. A partial failure during library initialization can leave an internal driver pointer uninitialized. Under specific error conditions, such as system resource exhaustion or database corruption, an application attempting to open an input method dereferences this null pointer without proper validation. This issue causes the application to crash, 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.