CVE-2026-90277 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
md/md-llbitmap: prevent create failure bitmap UAF
llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap.
If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex.
Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's device-mapper subsystem contains a critical race condition within the linear-log-bitmap implementation that leads to use-after-free vulnerabilities during initialization failures. The core of this issue lies in the sequence of operations performed by the llbitmap_create function, which is responsible for setting up bitmap structures used for tracking dirty regions in RAID arrays. In an effort to support scenarios where a new bitmap must be initialized and flushed immediately via helpers that access mddev->bitmap, the code publishes the pointer to the global device structure before fully validating or completing the superblock read operation through llbitmap_read_sb. This design choice creates a window of vulnerability where external readers can observe an incomplete or invalid state if the subsequent initialization steps fail.
When llbitmap_read_sb encounters an error during its execution, it triggers a cleanup routine that releases bitmap_info.mutex and subsequently frees the allocated llbitmap structure. However, at this specific point in the failure path, mddev->bitmap still holds the pointer to the now-freed memory location. This creates a classic use-after-free scenario because other kernel components continue to access mddev->bitmap under the assumption of stability provided by bitmap_info.mutex. Specifically, readers such as those exposed through /proc/mdstat rely on holding this mutex to safely collect statistics about the bitmap state. Without proper synchronization during cleanup, these readers can acquire the mutex after it has been released but before the pointer is cleared, allowing them to dereference a dangling pointer and access freed memory.
The operational impact of this vulnerability extends beyond simple kernel crashes or panics. Accessing invalid memory through a use-after-free condition can lead to unpredictable behavior, including data corruption within the RAID subsystem or potential privilege escalation if an attacker can control the contents of the freed memory region. This flaw undermines the integrity guarantees provided by the device-mapper layer and poses significant risks to systems relying on stable bitmap tracking for consistency checks and recovery operations. The vulnerability highlights a subtle but critical error in lock ordering and pointer lifecycle management within high-concurrency kernel subsystems where initialization sequences must be carefully synchronized with cleanup routines.
To mitigate this issue, the fix restructures the failure path of llbitmap_create to ensure that mddev->bitmap is cleared while bitmap_info.mutex remains held. By maintaining the mutex lock during the nullification of the pointer, any concurrent readers attempting to access the bitmap will either see a valid, live bitmap structure or no bitmap at all, but never a stale reference to freed memory. The actual deallocation of the failed llbitmap object occurs only after the mutex is dropped, ensuring that no active reader can hold a lock and simultaneously dereference invalid memory. This adjustment aligns with standard concurrency best practices for protecting shared pointers in kernel space.
From a classification perspective, this vulnerability corresponds to CWE-416 Use After Free, as it involves accessing memory after it has been freed due to improper synchronization during error handling. It also relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding the race condition between the cleanup thread and reader threads accessing mddev->bitmap. In terms of attack vectors, this could be leveraged in scenarios where an attacker can trigger repeated initialization failures on RAID devices, potentially leading to denial-of-service conditions or exploitation via memory corruption techniques described under MITRE ATT&CK technique T1203 Exploitation for Defense Evasion if the resulting instability allows further system compromise.