CVE-2026-43163

What it actually does

This is a Linux kernel use-after-free race in the md software RAID bitmap code. During an md array resize, __bitmap_resize() can unmap and free bitmap storage while bitmap_daemon_work() is still iterating over bitmap->storage.filemap without the required bitmap_info mutex. If the timing is hit, the md kernel module can dereference freed memory in write_page(), causing a General Protection Fault and kernel crash. The practical impact is local denial of service; the CVSS vector indicates local access, high attack complexity, low privileges, no user interaction, and availability impact only.

Why it matters to the business

Affected Linux systems using md software RAID with bitmaps may crash during or around array resize operations if the race is triggered. For organizations, this can mean unplanned downtime, interrupted storage services, failed maintenance operations, delayed rebuilds, and potential disruption to applications relying on local RAID-backed storage. The issue is not currently in CISA KEV, has very low EPSS, no known exploit maturity, and no ransomware association, so urgency is lower than for remotely exploitable or actively exploited flaws; however, systems performing md RAID resizing or exposing storage-management capabilities to non-root operators should be prioritized.

How an attack unfolds

An attacker first needs local access to a Linux system that uses the kernel md driver with bitmap-backed software RAID. They then need a way to initiate, influence, or race an md bitmap resize operation, such as through permitted storage-management tooling, delegated administrative workflows, or another local path that can trigger md array resizing. While the resize path frees or remaps bitmap storage, the attacker attempts to align timing with the md bitmap daemon's writeback activity. If bitmap_daemon_work() continues walking the old filemap while __bitmap_resize() has unmapped it, write_page() in md_mod can access freed memory and trigger a General Protection Fault. Successful exploitation is expected to crash the kernel or make the system unavailable rather than provide code execution or data theft.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the md/bitmap fix for the resize race. The corrected behavior holds mddev->bitmap_info.mutex during bitmap update activity so bitmap storage is not freed while the daemon is iterating it. Because exact fixed package versions were not provided, use the affected distribution's kernel advisories and changelog to identify the first fixed build for this issue. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting use of mdadm and storage-management interfaces to trusted administrators, avoiding online md array resize operations until patched, and scheduling any necessary RAID resizing during controlled maintenance windows. Disabling md write-intent bitmaps or avoiding bitmap-backed resize workflows may reduce exposure but can affect rebuild behavior and should be evaluated carefully before use.

How to confirm the fix worked

Confirm the running kernel is a fixed vendor build by checking the installed and booted kernel version with uname -r, package-manager metadata, and the distribution security advisory or changelog for the md/bitmap resize-race fix. Verify that systems have rebooted into the patched kernel, not merely installed it. Inventory md software RAID usage with tools such as /proc/mdstat and mdadm --detail, and prioritize hosts with bitmap-enabled md arrays. In a non-production test environment, resize operations should complete without kernel oops, General Protection Fault, or md_mod write_page() crashes. Review kernel logs after patching to ensure no recurring md bitmap fault messages appear during normal bitmap daemon or resize activity.

Typical attack path

1. Obtain local access to a Linux host using md software RAID with bitmap support enabled.
2. Identify an md array that can be resized or otherwise cause bitmap storage to be remapped.
3. Trigger or influence an md resize operation while bitmap daemon activity is occurring.
4. Race the resize path against bitmap writeback so bitmap->storage.filemap is freed while still in use.
5. Cause a kernel General Protection Fault in md_mod write_page().
6. Result in system crash, reboot, or storage-service outage.

How to detect it

Detection is primarily host-forensic and log-based because exploitation manifests as a kernel fault rather than a network-visible pattern. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and kdump/vmcore metadata for General Protection Faults or kernel oops events involving md_mod, write_page(), bitmap_daemon_work(), __bitmap_resize(), or md_bitmap_file_unmap(). Correlate any such events with mdadm activity, array grow/resize operations, storage automation jobs, local user sessions, sudo logs, and unexpected reboots. On systemd-based hosts, useful sources include journalctl -k, journalctl for mdadm/systemd storage units, auditd execve records for mdadm, sudo logs, and shell history where available. Because the same crash can occur accidentally during legitimate maintenance, treat matching logs as suspicious when they coincide with unplanned resize attempts, repeated failures, activity by non-storage administrators, or crashes outside approved maintenance windows. No public threat actors or active campaigns are currently associated with this issue.

• RIP: 0010:write_page
• write_page+0x22b/0x3c0 [md_mod]
• write_page+0x
• [md_mod]
• general protection fault
• General Protection Fault
• bitmap_daemon_work
• __bitmap_resize
• md_bitmap_file_unmap
• bitmap->storage.filemap
• md/bitmap
• mdadm --grow
• mdadm --resize

What your security team should do

• Inventory Linux systems using md software RAID, especially bitmap-enabled arrays, and rank those undergoing resize, rebuild, or storage maintenance as highest priority.
• Apply vendor kernel updates containing the md/bitmap mutex fix and reboot systems into the fixed kernel.
• Restrict mdadm, storage-management tooling, and any delegated resize workflows to trusted administrators only.
• Avoid online md array resize operations on unpatched systems unless operationally necessary and performed in a controlled maintenance window.
• Monitor kernel logs for md_mod write_page() General Protection Faults, bitmap resize stack traces, unexpected reboots, and storage-service outages.
• Because this is not KEV-listed, not known to be used in ransomware, has very low EPSS, and has no known exploit maturity, handle through normal kernel patch cycles unless affected hosts are exposed to untrusted local users or frequent RAID resizing.