CVE-2026-68179

The nsm driver vulnerability (CVE-2026-68179) is being scored as a CVSS 8.4 denial-of-service, but the severity metric badly misrepresents what's actually happening. This is not a typical DoS bug — it's a synchronization invariant violation that corrupts the kernel's internal lock bookkeeping, and the impact compounds over time rather than presenting as a single failure event. The technical mechanism matters: when copy_from_user() fails before mutex_lock() acquires the lock, the error-handling code path executes mutex_unlock() on a lock that was never held. The kernel's lockdep validator — if enabled — will report a "bad unlock balance," but this isn't equivalent to catching the bug. Lockdep must be compiled in, enabled at boot, AND the specific vulnerable code path must be exercised during testing. The PoC requires NSM_IOCTL_RAW with an invalid pointer, a narrow trigger that functional tests likely miss. More critically, production kernels from RHEL, Ubuntu, and Debian almost universally disable lockdep for performance reasons. On those systems, the corrupted lock state persists silently until reboot. The blast radius is the critical dimension that CVSS doesn't capture. A single unbalanced unlock doesn't just fail once — it poisons the kernel's internal lock dependency graph. Every subsequent lock acquisition that depends on that graph becomes potentially unsafe, and security decisions the kernel makes on that corrupted state may be wrong. The trigger complexity is low (one ioctl with an invalid pointer), but the impact propagation is architectural. The fix is mechanically trivial — return immediately on pre-lock copy_from_user() failure instead of jumping to the post-lock cleanup label. That triviality is itself significant. This pattern has appeared before in USB serial drivers (2016) and staging drivers (2019). Each time the post-mortem is identical: trivial fix, lockdep would have caught it, pattern recurs. The kernel's error-handling idioms (goto out for cleanup) canonicalize shared error labels without encoding when those assumptions break. The anti-pattern lives on because buggy examples serve as templates for new drivers. For defenders: verify whether the nsm driver is compiled into your running kernel image, regardless of lockdep status. If you're running production kernels with lockdep disabled — which is the default in enterprise distributions — treat this as a latent corruption engine rather than a caught bug. The EPSS probability of 0.00182 is optimistic precisely because it conditions on detection mechanisms that don't reliably apply to this pattern. Audit your kernel configurations for other drivers using the same "pre-lock failure jumps to post-lock out label" pattern; static analysis tools have caught this class, suggesting more examples remain undiscovered in the driver tree.

Reviewed through automated stages and approved by a human before publication.