CVE-2026-90276 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
md/md-llbitmap: stop daemon timer rearm on destroy
llbitmap_destroy() deletes pending_timer before flushing md_llbitmap_io_wq. However, daemon_work can still be queued or running after the timer has been deleted, and the daemon path can arm pending_timer again when it finds dirty chunks that are not ready to flush yet.
If that happens during teardown, pending_timer can remain armed after llbitmap is freed and later dereference freed memory.
Add a BITMAP_SHUTDOWN bit to llbitmap->flags, set it before deleting the timer, and make the timer and daemon paths stop queueing or rearming work once teardown starts. Cancel daemon_work before flushing the shared workqueue so no already queued daemon instance can race with the free. Use timer_shutdown_sync() so a daemon instance that passed the shutdown check before teardown cannot rearm the timer afterward.
BITMAP_SHUTDOWN is a runtime-only state. Mask it out when reading and updating the llbitmap superblock so the shutdown state is never loaded from disk or persisted to disk.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's md subsystem contains a race condition vulnerability within the linear bitmap implementation, specifically involving the interaction between timer management and workqueue execution during resource teardown. The core technical flaw lies in the sequence of operations performed by the llbitmap_destroy function. This routine is responsible for cleaning up the linear bitmap data structures when they are no longer needed. However, it deletes the pending_timer before flushing the md_llbitmap_io_wq workqueue. This ordering creates a critical window where daemon_work can still be queued or actively running even after the timer has been removed from the system's active timers list. If such an instance of daemon_work executes and identifies dirty chunks that are not yet ready to flush, it may attempt to rearm the pending_timer. Since this occurs during the teardown phase, the underlying memory structure for llbitmap might already be in a state where it is being freed or has been completely deallocated by other parts of the cleanup process.
This race condition leads directly to use-after-free vulnerabilities and potential kernel panics. When daemon_work rearms the timer after the llbitmap structure has been freed, any subsequent expiration of that timer will result in the kernel attempting to dereference a pointer to memory that is no longer valid or allocated. This constitutes a classic heap-based use-after-free scenario, which can be exploited by local attackers with sufficient privileges to trigger device removal or subsystem teardown sequences. The vulnerability highlights a failure in synchronization primitives during state transitions from active operation to shutdown. To address this issue, the fix introduces a new runtime-only flag named BITMAP_SHUTDOWN within the llbitmap flags structure. This flag serves as a global gatekeeper for all timer and workqueue activities related to the bitmap. It is set immediately before the deletion of the pending_timer, ensuring that any subsequent checks by daemon paths will detect this state and cease operations.
The mitigation strategy involves multiple layers of synchronization to ensure complete safety during teardown. First, both the timer callback path and the daemon_work execution path are modified to check for the BITMAP_SHUTDOWN flag. If this flag is set, these functions stop queueing new work or rearming timers immediately. Second, the order of operations in llbitmap_destroy is adjusted so that daemon_work is explicitly cancelled before flushing the shared md_llbitmap_io_wq workqueue. This ensures that no already queued instance of daemon can race with the memory free operation. Furthermore, timer_shutdown_sync() is utilized instead of standard timer deletion functions. This function guarantees that any daemon instance that passed the shutdown check prior to teardown cannot rearm the timer afterward by synchronously waiting for all pending timers to complete or be cancelled. These changes effectively eliminate the window where stale pointers could lead to memory corruption.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper synchronization during resource deallocation. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, given the race condition between timer expiration and workqueue execution. In terms of MITRE ATT&CK mapping, this type of vulnerability is often associated with T1059, Command and Scripting Interpreter, if exploited for arbitrary code execution via kernel panic or memory corruption techniques that allow privilege escalation to root level. The exploitation typically requires local access but can lead to significant system instability or compromise depending on the context in which the md subsystem operates.
To mitigate this vulnerability, systems must apply the specific Linux kernel patch that implements these synchronization fixes. Administrators should ensure their kernels are updated to versions containing the fix for llbitmap_destroy race conditions. For environments where immediate patching is not feasible, monitoring system logs for unexpected device removals or I/O errors in md subsystem components may provide early indicators of exploitation attempts, although such attacks often result in immediate crashes rather than stealthy data exfiltration. Additionally, enforcing strict access controls on devices managed by the md subsystem can reduce the attack surface available to local users attempting to trigger teardown sequences. The introduction of BITMAP_SHUTDOWN as a runtime-only state also ensures that this shutdown logic is not persisted to disk via llbitmap superblock updates, preventing any potential persistence mechanisms or confusion during subsequent system boots where stale states might otherwise be misinterpreted by the kernel's initialization routines.