CVE-2026-93261 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Fix NULL pointer dereference in __lock_set_class()
register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check:
class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes;
If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference.
Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel's lock dependency validator, known as lockdep, is a critical debugging subsystem designed to detect potential deadlocks and locking inconsistencies during runtime. A significant flaw was identified within the internal function __lock_set_class(), which serves as part of the mechanism for tracking lock classes and their relationships across different execution contexts. This vulnerability stems from an improper handling of return values when registering new lock classes, leading to memory corruption that can destabilize the kernel's concurrency control mechanisms. The issue highlights a gap in defensive programming practices within the core locking infrastructure, where assumptions about successful allocation or registration are not sufficiently validated against failure conditions.
The technical root cause lies in the interaction between register_lock_class() and __lock_set_class(). When the system attempts to record information about a lock instance for dependency tracking purposes, it calls register_lock_class() to allocate space within the internal lock class pool. This function can fail under several specific circumstances: exhaustion of the available lock class slots, failure to acquire necessary graph locks due to contention or state issues, or validation failures regarding the key properties of the lock being registered. In these scenarios, register_lock_class() returns a NULL pointer to indicate failure. However, __lock_set_class() proceeds to use this return value directly in arithmetic operations without verifying its validity first. Specifically, it calculates an index by subtracting the base address of lock_classes from the returned class pointer.
When the returned pointer is NULL, this subtraction results in a large negative integer or a wildly incorrect positive offset due to unsigned integer wrapping behavior inherent in pointer arithmetic on many architectures. This corrupted value is then stored in hlock->class_idx within the held locks structure associated with the current task context. The severity of this flaw escalates when subsequent locking operations occur, as functions like reacquire_held_locks() rely on accurate class indices to retrieve lock metadata. By passing a corrupted index into hlock_class(), the kernel attempts to dereference memory at an invalid location derived from that bad offset. This leads directly to either a NULL pointer dereference or an out-of-bounds memory access, which typically manifests as a kernel panic or oops, causing system instability and potential denial of service for all processes running on the affected host.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes a NULL Pointer Dereference, specifically occurring due to missing validation of function return values before use in critical logic paths. It also relates closely to CWE-190, Integer Overflow or Wraparound, as the arithmetic operation on an invalid pointer produces an erroneous index that exceeds valid memory bounds. In terms of adversarial tactics, while this is primarily a stability issue rather than a direct privilege escalation vector exploitable by external attackers without prior code execution context, it falls under MITRE ATT&CK techniques related to Denial of Service via resource exhaustion or system crash if triggered repeatedly in high-contention environments where lock class registration fails frequently.
The operational impact of this vulnerability is primarily centered on system reliability and availability. In production environments with complex locking patterns or heavy concurrency, hitting the limits of the lock class pool can trigger these failure paths more readily. A successful exploitation does not necessarily grant an attacker direct code execution but serves as a reliable method to crash the kernel, resulting in immediate service interruption. For systems running critical workloads where uptime is paramount, such instability poses a significant risk to business continuity and data integrity if automatic restart mechanisms are insufficient or delayed.
Mitigation for this issue involves applying the upstream Linux kernel patch that introduces explicit NULL checks within __lock_set_class(). This fix ensures that when register_lock_class() fails, the function returns early without proceeding to perform invalid pointer arithmetic. The corrected logic mirrors the existing error handling in __lock_acquire(), which already properly validates its inputs before accessing lock class structures. Administrators should ensure their systems are updated with kernel versions containing this patch. Additionally, monitoring for frequent lockdep warnings or oops messages can help identify environments where lock class exhaustion is occurring, allowing for architectural adjustments to reduce the number of distinct lock classes tracked if necessary.