CVE-2026-99256 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix issue with background work locking
dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning:
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE))
triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel's device-mapper cache subsystem contained a concurrency control flaw related to the locking mechanism for its background work processing. Specifically, the code utilized a read-write semaphore, known as rw_semaphore, designated as background_work_lock to manage access during critical operations such as suspending and resuming the cache device. The fundamental issue stems from the strict owner semantics inherent in rw_semaphores within the Linux kernel implementation. When a process acquires a write lock on an rw_semaphore, it becomes the exclusive owner of that lock until it explicitly releases it. However, the dm cache code did not guarantee that the thread or process acquiring the lock was the same entity releasing it. This violation of ownership semantics creates a race condition and leads to undefined behavior, which is detectable when debugging features are enabled in the kernel configuration.
This vulnerability manifests clearly during specific administrative operations involving device-mapper devices. When an administrator executes commands such as dmsetup suspend followed by dmsetup resume on a cache device, the system attempts to lock background_work_lock for writing and subsequently unlock it upon completion of the operation. If these actions are performed by different execution contexts or if preemption occurs between locking and unlocking in a way that breaks ownership continuity, the kernel's debug infrastructure detects the mismatch. With CONFIG_DEBUG_RWSEMS enabled, this triggers a critical warning condition indicating that rwsem_owner does not match current task context. Such warnings indicate potential data corruption, deadlocks, or system instability under concurrent load conditions where background migration tasks interact with device state changes.
The operational impact of this flaw includes kernel panics or persistent debugging warnings in production environments running debug kernels, and potentially subtle race conditions affecting cache consistency in optimized builds. The incorrect locking strategy undermines the reliability of the dm-cache subsystem, which is critical for performance optimization by caching frequently accessed data blocks on faster storage media like SSDs while backing them with slower HDDs. Any disruption to background work processing can lead to inconsistent state transitions during suspend and resume cycles, potentially causing I/O errors or loss of cached metadata integrity. This affects system stability and reliability in virtualized environments or servers relying heavily on device-mapper caching for performance tuning.
To resolve this issue, the locking mechanism was refactored from an rw_semaphore to a spinlock paired with a wait queue structure. Spinlocks are appropriate here because they do not enforce strict owner semantics regarding which thread must release them; any context holding the lock can unlock it safely without violating kernel assumptions about ownership continuity. The solution leverages existing infrastructure within dm cache, specifically repurposing the migration_wait wait queue and nr_allocated_migrations counter that were previously underutilized. By integrating these into a new background_work queue mechanism, the code ensures proper synchronization between threads performing background migrations and those managing device state changes like suspension and resumption. This change eliminates the ownership mismatch while maintaining efficient concurrency control for high-frequency background tasks.
From a vulnerability classification perspective, this issue aligns with CWE-667, which denotes improper locking in concurrent programming scenarios where lock acquisition and release are not properly matched or managed across execution contexts. In terms of attack surface and behavior mapping under MITRE ATT&CK techniques, while primarily an internal stability flaw rather than a direct exploitation vector for external attackers, it relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The improper synchronization allows potential race conditions that could be triggered by local users with sufficient privileges to manipulate device-mapper configurations. Mitigation strategies involve applying the kernel patch that replaces the rw_semaphore with a spinlock and wait queue combination, ensuring robust handling of background work serialization without violating ownership constraints. System administrators should ensure their kernels are updated to versions containing this fix, particularly those running dm-cache devices in production environments where suspend-resume cycles occur regularly for maintenance or live migration purposes.