Cloudanix VulnDB

CVE-2026-68178

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A local user on certain Linux systems could crash the machine or run malicious code inside the kernel by keeping a device open while its driver module is removed.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The NSM misc driver's file_operations lack an owner pointer, so misc_open() does not acquire a module reference; an open /dev/nsm descriptor can outlive rmmod, allowing subsequent ioctl calls to execute code from the now-unloaded module.

Why it matters to the business

On systems where the nsm driver is built as a loadable module, a local user can trigger kernel crashes, memory corruption, or arbitrary code execution in kernel context, leading to denial of service or full system compromise.

How an attack unfolds

An attacker obtains a file descriptor to /dev/nsm, forces or waits for the nsm module to be unloaded via rmmod, then issues an ioctl on the stale descriptor; the kernel invokes function pointers that now point into freed module memory.

How to fix it

Apply the upstream fix that sets nsm_dev_fops.owner = THIS_MODULE; rebuild and deploy a kernel containing the resolution for CVE-2026-68178; if the driver must remain modular, ensure it is never unloaded while any /dev/nsm descriptors exist.

How to confirm the fix worked

Confirm the nsm_dev_fops structure initializer contains .owner = THIS_MODULE; attempt to open /dev/nsm, rmmod the module, and verify the module reference count prevents unload while the descriptor is open.

Typical attack path

  1. Open /dev/nsm to obtain a file descriptor
  2. Unload the nsm kernel module (rmmod nsm)
  3. Issue ioctl (or other f_op) on the retained descriptor
  4. Execute code or trigger fault from unloaded module text

How to detect it

Review kernel logs for oops/panic traces referencing nsm or misc device ioctls after module unload events; correlate audit logs showing open of /dev/nsm followed by rmmod of the nsm module.

What your security team should do

  • Prioritize kernel updates containing the NSM owner fix on all systems exposing /dev/nsm
  • Audit initramfs and module-load policies to ensure nsm is either built-in or protected from premature unload
  • Add monitoring for unexpected rmmod of nsm while device nodes are open

The record

In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.

Affected packages

Ecosystem Package Introduced Fixed