CVE-2026-43163 Overview
CVE-2026-43163 is a use-after-free race condition in the Linux kernel's md/bitmap subsystem. The flaw triggers a General Protection Fault (GPF) in write_page() during MD array resize operations. The race occurs between bitmap_daemon_work() and __bitmap_resize(), where the daemon iterates over bitmap->storage.filemap without locking while the resize path frees that storage via md_bitmap_file_unmap(). Because quiesce() does not stop the md thread, concurrent access to freed pages becomes possible. The upstream fix holds mddev->bitmap_info.mutex during the bitmap update to serialize access. The vulnerability impacts kernel stability and integrity for systems using MD software RAID with bitmap support.
Critical Impact
Concurrent execution of the bitmap daemon and array resize paths leads to a kernel use-after-free, causing a General Protection Fault and a system crash on affected MD RAID configurations.
Affected Products
- Linux kernel md_mod driver (MD software RAID with bitmap support)
- Multiple stable kernel branches receiving backports across the eight referenced commits
- Distributions shipping unpatched Linux kernels with the affected MD bitmap code
Discovery Timeline
- 2026-05-06 - CVE-2026-43163 published to NVD
- 2026-05-06 - Last updated in NVD database
Technical Details for CVE-2026-43163
Vulnerability Analysis
The vulnerability is a kernel-mode use-after-free triggered by a race between two MD bitmap code paths. The bitmap daemon thread calls bitmap_daemon_work(), which walks bitmap->storage.filemap to flush dirty bitmap pages. In parallel, an administrator-initiated array resize calls __bitmap_resize(), which invokes md_bitmap_file_unmap() to free the previous filemap storage before installing a new one.
The daemon takes no lock that protects against this teardown. As a result, it can dereference page pointers that the resize path has already freed. The faulting instruction is reported at RIP: 0010:write_page+0x22b/0x3c0 [md_mod], indicating the fault occurs while the daemon is writing a stale page reference.
The expectation that quiesce() would prevent this race does not hold, because quiesce() does not stop the md thread that runs the daemon work. The kernel therefore allows two concurrent writers and readers of the same data structure with no synchronization barrier between free and use.
Root Cause
The root cause is missing mutual exclusion on bitmap->storage.filemap. The resize path frees and replaces the filemap without holding a lock that the daemon also respects. This is a classic Race Condition leading to Use-After-Free in shared kernel state.
Attack Vector
Triggering the fault requires the ability to initiate an MD array resize concurrent with normal bitmap daemon activity. The condition is reachable on systems running MD RAID with a bitmap, typically by a privileged local operator running mdadm --grow while the array is active. The fix serializes both paths under mddev->bitmap_info.mutex.
The vulnerability manifests in the bitmap daemon and resize functions. See the upstream commits referenced below for the exact synchronization changes.
Detection Methods for CVE-2026-43163
Indicators of Compromise
- Kernel oops or General Protection Fault with RIP pointing to write_page+0x22b/0x3c0 [md_mod] in dmesg or /var/log/kern.log.
- System crash or hang correlated with MD array resize activity (mdadm --grow, --size, or component count changes).
- Stack traces referencing bitmap_daemon_work, __bitmap_resize, or md_bitmap_file_unmap.
Detection Strategies
- Monitor kernel ring buffer events for md_mod faults and correlate with concurrent administrative changes to MD arrays.
- Inventory hosts running MD RAID with bitmap enabled and compare running kernel versions against the patched stable branches.
- Track invocations of mdadm --grow in audit logs to identify systems exposed to the race window.
Monitoring Recommendations
- Forward kern.log and dmesg to a centralized log platform and alert on general protection fault strings tagged with [md_mod].
- Alert on unexpected reboots or kernel panics on storage-tier hosts using software RAID.
- Track kernel package versions across the fleet and flag hosts that have not received the fix from the referenced stable commits.
How to Mitigate CVE-2026-43163
Immediate Actions Required
- Identify hosts running MD software RAID with bitmap support and prioritize them for kernel updates.
- Apply vendor kernel updates that include the upstream fix locking mddev->bitmap_info.mutex during bitmap updates.
- Avoid running array resize operations on unpatched kernels; schedule resizes only after the patched kernel is in place.
Patch Information
The fix is upstream in the Linux kernel and has been backported across multiple stable branches. The relevant commits are Kernel Git Commit 140cc83, Kernel Git Commit 46ef85f, Kernel Git Commit 5f73c8b, Kernel Git Commit 9a6f8cd, Kernel Git Commit a437e3b, Kernel Git Commit d3af624, Kernel Git Commit d92b8fa, and Kernel Git Commit ebcacc7. Apply the kernel update from your distribution that contains the corresponding backport.
Workarounds
- Defer MD array resize operations until the patched kernel is deployed.
- Where feasible, stop the array or unmount filesystems before changing array geometry to remove concurrency with the bitmap daemon.
- Restrict privileged access so that only authorized administrators can invoke mdadm resize operations on production storage.
# Verify running kernel and MD bitmap status before changes
uname -r
cat /proc/mdstat
mdadm --detail /dev/md0 | grep -i bitmap
# After patching, confirm the kernel package version reflects the fix
rpm -q kernel # RHEL/CentOS
dpkg -l | grep linux-image # Debian/Ubuntu
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


