The vulnerability arises in the Linux kernel’s lockdep subsystem where stale entries in the class_cache array persist after a lock class is deleted. When a lock is subsequently acquired, the stale entry causes the kernel to assign an invalid class index and trigger a DEBUG_LOCKS_WARN_ON warning. The flaw is a memory safety issue (CWE‑825). While the bug does not directly crash the kernel, repeated warnings can degrade performance and, in heavily debugged or heavily loaded environments, may contribute to subtle instability. Based on the description, it is inferred that the underlying weakness stems from inadequate validation of cached class pointers during lock acquisition. There is no evidence of direct user‑space exploitation, and the kernel’s internal lock logic is the primary surface.

All Linux kernel releases built with CONFIG_LOCKDEP enabled contain this issue. The affected builds are any upstream Linux kernels prior to the commit that added lock_class_cache_is_valid. This includes kernels shipped by all major distributions when lockdep is active, regardless of vendor. No specific vendor or version restriction beyond the timing of the patch.

The EPSS score is below 1 % and the vulnerability is not listed in CISA’s KEV catalog. A CVSS score of 5.5 indicates moderate severity, but the internal nature of the bug suggests a low probability of exploitation. The most likely trigger involves internal events such as unloading a module or unregistering a key that frees a lock class, which generally requires kernel‑process or root access. For privileged users, repeated warnings and potential instability are the principal risks; for unprivileged users the risk remains low. The likelihood of remote or non‑privileged exploitation is effectively negligible.