A kernel module that implements a miscellaneous (misc) device can be loaded as a loadable module. When a user opens the character device /dev/nsm, the driver’s file operations are installed with a missing module owner reference. Consequently, an open file descriptor can survive the removal of the module that supplies the device’s ioctl handlers. The descriptor then allows execution of IOCTL commands that finally call into code that has already been unloaded from memory. This use‑after‑free scenario can lead to a kernel crash or, in the worst case, arbitrary code execution with kernel privileges if the attacker can control the IOCTL payload. The weakness is a classic use‑after‑free error caused by an unset owner field. Based on the description, the most likely attack vector is a local user with sufficient privileges to unload the module and subsequently issue IOCTLs through the retained descriptor.

The flaw exists in the Linux kernel’s misc subsystem, affecting all kernels that expose the nsm misc driver as a loadable module. It is not tied to a particular Linux distribution version because the change was applied universally to the kernel source tree referenced in the CVE reports. Systems that compile the Linux kernel with the nsm driver as a module and expose /dev/nsm are impacted. No specific vendor or product version details are listed beyond the generic Linux kernel identifier.

The issue stems from a module reference not being pinned while the device remains open, creating a vulnerable use‑after‑free. The CVSS score of 7.8 indicates high severity, and the EPSS score is < 1%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA KEV catalog, suggesting no confirmed widespread exploitation yet. Based on the description, the likely attack vector is local: an attacker would need to open /dev/nsm, unload the module, and then issue IOCTL commands through the remaining descriptor; this scenario implies access to the console or root privileges to unload the module. The risk remains high due to the kernel-level nature of the flaw, and automated exploitation could be developed once the module’s code to parse IOCTL parameters is understood.