Bug 2547411 (CVE-2026-107170)

Summary: CVE-2026-107170 m17n-lib: NULL dereference in minput_open_im() after failed m17n_init()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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).
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2547605    
Bug Blocks:    

Description OSIDB Bzimport 2026-10-07 12:02:49 UTC 
A flaw was found in m17n-lib. A partial failure during m17n_init() can leave the internal minput_driver pointer NULL. A subsequent call to minput_open_im() 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 m17n_init(), 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: m17n_init() calls a chain of module initializers (mcharset__init, mcoding__init, mcharset__load_from_database, mcoding__load_from_database, mlang__init, mlocale__init) and jumps to an `err:` label on the first failure, which skips the subsequent minput__init() call entirely. minput__init() is the only place the global minput_driver pointer is assigned; it is NULL otherwise. src/input.c:4786 then does `driver = minput_driver;` 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.