CVE-2026-43278

What it actually does

CVE-2026-43278 is a Linux kernel memory-management flaw in request-based device-mapper handling. When cloned request bios complete, the kernel can leave a stale request bio pointer behind. Later teardown paths may treat that stale pointer as valid and free the same cloned bios a second time, causing use-after-free or double-free conditions in kernel memory. The described trigger involves request-based device-mapper targets such as dm-multipath over PCIe NVMe storage, where completion and clone cleanup paths can race or execute sequentially against already-freed bio structures. Because this occurs in kernel context, successful exploitation may allow a local privileged or low-privileged user with access to relevant block-device operations to crash the host or potentially gain elevated privileges, depending on kernel configuration, memory layout, and exploitability of the freed objects.

Why it matters to the business

The main operational risk is host instability or compromise on Linux systems using affected kernels, especially systems relying on device-mapper features such as dm-multipath for storage resilience. A successful attack or accidental trigger could cause kernel crashes, storage I/O disruption, application outages, data corruption risk, or, in the worst case, local privilege escalation to full system control. The CVSS score indicates high severity, but current exploitation signals are low: EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. Organizations with critical Linux storage infrastructure, NVMe-backed multipath deployments, or multi-user systems should still prioritize kernel updates because kernel memory corruption flaws can have severe consequences even when exploitation is not yet widespread.

How an attack unfolds

An attacker needs local access to an affected Linux system and the ability to exercise block-device I/O paths that use request-based device-mapper targets. They would attempt to generate storage operations through a configuration such as dm-multipath over NVMe so that cloned request bios are completed and freed during the normal block completion path while the clone request still retains a stale bio pointer. When the device-mapper clone teardown path later runs, it can attempt to unprepare and free the same bio structures again. This double-free/use-after-free can corrupt kernel heap state. A simple exploit path would focus on denial of service by reliably triggering a kernel panic or storage subsystem failure. A more advanced exploit would attempt to shape kernel heap allocations around the freed bio objects and convert the memory corruption into privilege escalation or arbitrary kernel code execution. There is no indication from the provided intelligence that this vulnerability is currently exploited in the wild.

How to fix it

Upgrade to a Linux kernel version that includes the device-mapper fix clearing the cloned request bio pointer when the last cloned bio completes. Because no exact fixed versions were provided, use the security advisories and kernel packages from the relevant Linux distribution or kernel vendor and confirm that the patch for this issue is included. Prioritize systems using dm-multipath, request-based device-mapper targets, NVMe storage, or other high-availability storage stacks. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads from performing direct or heavy block-device I/O, reviewing whether vulnerable request-based device-mapper configurations can be temporarily avoided, and increasing monitoring for kernel warnings, crashes, and storage errors. Mitigations should be treated as temporary; the durable fix is a patched kernel followed by reboot into that kernel.

How to confirm the fix worked

Confirm exposure by inventorying Linux kernel versions and checking vendor advisories or changelogs for inclusion of the fix for the device-mapper cloned request bio pointer cleanup. Validate whether device-mapper and multipath are in use with standard tools such as lsblk, dmsetup, multipath -ll, and kernel module listings. After remediation, verify the system has rebooted into the patched kernel, not merely installed it. Review package manager output and kernel build metadata to confirm the active kernel contains the fix. On representative systems, perform normal storage failover and I/O validation for dm-multipath or device-mapper workloads and monitor dmesg/journald for kernel oops, use-after-free, double-free, slab corruption, block layer, NVMe, or device-mapper errors. The absence of crashes is not proof of security; patch confirmation through vendor metadata is the primary validation method.

Typical attack path

1. Obtain local access to an affected Linux host, typically with a shell or the ability to run code as an unprivileged or low-privileged user.
2. Identify that the host is running a vulnerable Linux kernel and uses request-based device-mapper storage paths, such as dm-multipath over NVMe.
3. Generate crafted or high-volume block I/O that causes cloned request bios to complete through the vulnerable completion path.
4. Trigger clone request teardown after the cloned bios have already been freed, causing a stale rq->bio pointer to be processed again.
5. Cause kernel memory corruption through double-free or use-after-free of bio structures.
6. Leverage the corruption to crash the host, disrupt storage I/O, or attempt local privilege escalation.

How to detect it

To assess prior exploitation, review kernel logs, persistent journal entries, crash dumps, and storage subsystem telemetry for signs of kernel memory corruption around device-mapper, multipath, NVMe, block request completion, bio freeing, or slab allocator failures. Useful sources include dmesg, /var/log/kern.log, /var/log/messages, journald, kdump/vmcore artifacts, crash utility output, auditd process execution logs, EDR telemetry for local code execution, and storage monitoring events. Look for kernel oops or panic traces involving functions such as blk_rq_unprep_clone, dm_end_request, dm_done, dm_softirq_done, dm_complete_request, end_clone_request, blk_complete_request, bio_endio, blk_mq_end_request_batch, nvme_complete_batch, and nvme_pci_complete_batch. Also investigate unexplained host crashes, sudden reboots, I/O errors, multipath path flapping, NVMe completion anomalies, or slab allocator messages reporting double-free, use-after-free, invalid free, list corruption, or general protection faults. Because no public exploit or fixed IOC is provided, detection should focus on behavioral and crash-forensic indicators rather than network signatures. Correlate suspicious kernel events with local user sessions, recently executed storage stress tools, container workloads with block-device access, and unusual high-volume reads/writes to device-mapper or multipath devices.

• blk_rq_unprep_clone
• dm_end_request
• dm_done
• dm_softirq_done
• dm_complete_request
• end_clone_request
• blk_complete_request
• bio_endio
• blk_mq_end_request_batch
• nvme_complete_batch
• nvme_pci_complete_batch
• BUG: KASAN: use-after-free
• BUG: KASAN: double-free
• double free
• use-after-free
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic
• slab corruption
• corrupted list
• list_del corruption
• dm-multipath
• device-mapper: multipath
• blk_update_request: I/O error
• nvme nvme

What your security team should do

• Inventory Linux systems running affected kernel branches, prioritizing servers with dm-multipath, request-based device-mapper, PCIe NVMe storage, shared multi-user access, or critical production storage roles.
• Apply vendor-provided kernel updates that include the fix and reboot systems into the patched kernel; track reboot completion separately from package installation.
• Treat this as high severity for critical Linux infrastructure despite low EPSS and no KEV status, because successful exploitation occurs in kernel context and can affect confidentiality, integrity, and availability.
• Restrict local access on unpatched systems, especially for untrusted users, build workloads, containers with elevated device access, and processes that can generate direct block-device I/O.
• Review storage architecture for use of request-based device-mapper targets and dm-multipath, and prioritize testing and patch rollout for those hosts first.
• Increase monitoring for kernel oops, panic, slab allocator corruption, bio/request lifecycle warnings, NVMe completion errors, and unexplained storage path resets.
• Preserve crash dumps, vmcores, kernel logs, and audit logs from suspected incidents before rebooting or reimaging, as exploitation evidence may exist only in volatile or crash artifacts.
• Do not rely on exploit availability as the patching trigger; kernel memory corruption vulnerabilities can become exploitable after patch diffing even when initially reported without a public exploit.