REDHAT-BUG-2547409: Medium severity GNU m17n-lib vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
What input must an attacker provide to trigger the CPU exhaustion?
The affected process must handle crafted M-text containing an invalid UTF-8 sequence whose lead byte is 0xFE or 0xFF. A crafted .mim database entry containing byte 0xFF was independently confirmed to trigger the issue.
Which deployments are exposed in practice?
Deployments are exposed when m17n-lib processes attacker-controlled or otherwise untrusted M-text input, including untrusted .mim database content. The provided data does not establish whether any particular default configuration loads such input.
How can administrators recognize exploitation or reproduce the condition?
A vulnerable process can spin at approximately 100% CPU and require external termination after processing the crafted input. The confirmed reproduction consumed about 4.9 seconds of CPU time during a five-second observation window.