CVE-2026-107168: M17n-lib: parser infinite loop on malformed utf-8 in count_utf_8_chars()
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.
Other sources
A flaw was found in m17n-lib. By providing crafted input containing an invalid UTF-8 character sequence, an attacker can cause the text parsing function to enter an infinite loop. This issue leads to sustained high CPU utilization, resulting in a Denial of Service (DoS) for the affected application.
— MITRE
Affected Software
Event History
Frequently Asked Questions
What input is required to trigger the CPU exhaustion?
The input must contain an invalid UTF-8 sequence with a lead byte in the 0xFE-0xFF range. A crafted .mim database entry containing byte 0xFF was independently reproduced as a trigger.
How can I recognize exploitation or reproduce the impact?
An affected application can spin at approximately 100% CPU while processing the crafted input and may not recover without external termination. In the reported reproduction, the process consumed about 4.9 seconds of CPU during a 5-second window.