Linux Kernel CVE-2025-68336

Requires a Linux kernel compiled with spinlock lock-debugging enabled (CONFIG_DEBUG_SPINLOCK-class options); the affected debug_write_lock_before() path does not exist in kernels built without lock debugging. Exploitation further requires concurrent local execution of raw write-lock acquisition across CPUs (observed on the do_exit / call_usermodehelper_exec_async kworker path), i.e., local, timing-dependent conditions - not remote or unauthenticated access. Limiting factors: standard production/defconfig kernels usually omit lock debugging and are therefore not affected, the race is non-deterministic and timing-sensitive, and the practical impact is confined to lock-debug state rather than user-facing data.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, score 7.5) is inconsistent with the technical reality and appears to be an automated worst-case Linux-kernel CNA scoring. The vulnerability is a data-race inside optional lock-debugging code reached via kernel-internal task-exit paths - it is not a network-reachable, unauthenticated condition, so AV:N/PR:N materially overstates real risk. Confirming signals of low priority: EPSS is 0.17% (7th percentile), there is no CISA KEV listing, and no public exploit is identified. The realistic worst case is a debug-kernel availability blip or false KCSAN report, not a remotely triggerable DoS. CONFLICT TO NOTE: CVSS indicates a remote network vector with high availability impact, but the description and code path imply a local, debug-config-only race with negligible impact - treat the 7.5 as inflated and verify against the actual kernel config in use. Production kernels without lock debugging enabled are not affected at all.

On a kernel built with spinlock lock-debugging enabled, two tasks concurrently exiting (e.g., via call_usermodehelper_exec_async / do_exit on separate CPUs) race on the same raw write-lock state word, producing a KCSAN-detected data-race and potentially inconsistent lock-debug state or a transient availability issue. No public POC exists, and triggering it requires the debug configuration plus precise timing, so this is realistically a correctness/sanitizer finding rather than a practical attack.