Cloudanix VulnDB

CVE-2026-68179

High · 8.4

CVSS

8.4

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A coding mistake in an error-handling path inside a core operating-system component can let ordinary local programs crash the machine.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw causes an unconditional mutex unlock in the error path of an ioctl handler even when the lock was never acquired due to a prior copy_from_user failure.

Why it matters to the business

Unprivileged local processes can trigger kernel warnings or crashes, leading to denial of service on affected systems and potential operational disruption.

How an attack unfolds

An attacker invokes the affected ioctl with an invalid user pointer so that copy_from_user fails before the mutex is taken; execution then falls through to the shared unlock label, producing a bad unlock balance that lockdep detects and that may destabilize the kernel.

How to fix it

Apply the upstream kernel patch that returns immediately from the pre-lock copy_from_user failure instead of jumping to the shared unlock label; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Inspect the nsm_dev_ioctl function to confirm the copy_from_user failure path now returns directly and that the unlock occurs only after a successful lock acquisition.

Typical attack path

  1. Open the miscdevice exposing the ioctl
  2. Issue the raw ioctl command supplying an invalid user-space pointer
  3. Trigger the pre-lock copy_from_user failure
  4. Reach the common out label and execute the unlock of a never-acquired mutex

How to detect it

Search kernel logs for lockdep warnings mentioning bad unlock balance and the nsm_dev_ioctl symbol; correlate with process activity issuing the affected ioctl.

  • WARNING: bad unlock balance detected
  • nsm_dev_ioctl
  • release lock (&global_nsm.lock)

What your security team should do

  • Prioritize kernel updates on all systems exposing the miscdevice
  • Enable lockdep and monitor dmesg for bad unlock balance warnings
  • Restrict unprivileged access to the device node until patched

The record

In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.

Affected packages

Ecosystem Package Introduced Fixed