CVE-2026-107170: M17n-lib: null dereference in minput_open_im() after failed m17n_init()
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).
Other sources
A flaw was found in m17n-lib. A partial failure during m17ninit() can leave the internal minputdriver pointer NULL. A subsequent call to minputopenim() can dereference this NULL pointer instead of returning an initialization error, resulting in a crash. No reproducer was supplied for this claim, and attempts to force the specific precondition (an early module-init failure inside m17ninit(), e.g. via a bogus M17NDIR) did not trigger it directly -- the library tolerates a missing or invalid database path gracefully in the tested configuration. Source review of src/m17n.c confirms the claimed code path is real: m17ninit() calls a chain of module initializers (mcharsetinit, mcodinginit, mcharsetloadfromdatabase, mcodingloadfromdatabase, mlanginit, mlocaleinit) and jumps to an err: label on the first failure, which skips the subsequent minputinit() call entirely. minputinit() is the only place the global minputdriver pointer is assigned; it is NULL otherwise. src/input.c:4786 then does driver = minputdriver; and src/input.c:4799 dereferences it unconditionally via im->driver = driver; with no NULL check. The crash is real but requires one of the six earlier module initializers to fail first (e.g. under memory pressure or a corrupted system m17n database), a narrower precondition than the other three issues reported alongside this one. No live reproduction was achieved; this assessment is based on code review alone.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The issue is rated as locally exploitable and does not require privileges or user interaction. Exploitation still depends on causing a partial m17n-lib initialization failure and then reaching an input-method open operation.
Can an invalid M17NDIR setting be used to confirm the issue?
Not reliably. Testing with a bogus M17NDIR did not directly trigger the condition because the tested configuration tolerated a missing or invalid database path gracefully.
How can I determine whether an application is exposed?
An application is exposed to the crash path if it continues to call the input-method open API after m17n-lib initialization has partially failed. The available data confirms this path in source review, but no reproducer was supplied.