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.