REDHAT-BUG-2547411: Low severity GNU m17n-lib vulnerability

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.