CVE-2026-43278: dm: clear cloned request bio pointer when last clone bio completes
In the Linux kernel, the following vulnerability has been resolved:
dm: clear cloned request bio pointer when last clone bio completes
Stale rq->bio values have been observed to cause double-initialization of
cloned bios in request-based device-mapper targets, leading to
use-after-free and double-free scenarios.
One such case occurs when using dm-multipath on top of a PCIe NVMe
namespace, where cloned request bios are freed during
blk_complete_request(), but rq->bio is left intact. Subsequent clone
teardown then attempts to free the same bios again via
blk_rq_unprep_clone().
The resulting double-free path looks like:
nvme_pci_complete_batch()
nvme_complete_batch()
blk_mq_end_request_batch()
blk_complete_request() // called on a DM clone request
bio_endio() // first free of all clone bios
...
rq->end_io() // end_clone_request()
dm_complete_request(tio->orig)
dm_softirq_done()
dm_done()
dm_end_request()
blk_rq_unprep_clone() // second free of clone bios
Fix this by clearing the clone request's bio pointer when the last cloned
bio completes, ensuring that later teardown paths do not attempt to free
already-released bios.
Security readout for executives and security teams
Plain-English summary
A Linux kernel flaw can mishandle completed storage requests and free the same memory twice. On affected systems using request-based device-mapper configurations, particularly dm-multipath over PCIe NVMe, this may crash the host or corrupt kernel memory. The supplied CVSS assessment also allows possible confidentiality and integrity impact from a local, low-privileged attacker.
Executive priority
Treat as a high-priority infrastructure update where multipath NVMe or request-based device-mapper storage is present. Schedule prompt maintenance for exposed production, virtualization, and storage hosts. Other Linux systems should still be checked through vendor advisories because the supplied version mapping is incomplete and distribution backports may alter exposure.
Technical view
Completed cloned bios may be freed while the clone request retains a stale bio pointer. Later teardown through blk_rq_unprep_clone() can free those bios again, producing use-after-free or double-free conditions. The kernel fix clears the pointer when the final cloned bio completes. Exact triggering conditions beyond the described device-mapper and NVMe case are not documented here.
Likely exposure
Prioritize Linux hosts using request-based device-mapper targets, especially dm-multipath layered over PCIe NVMe namespaces. The supplied affected-version data includes several kernel series but is ambiguous and should not be treated as a complete distribution-specific version map. Systems require local access according to the CVSS vector.
Exploitation context
The supplied record is not listed in KEV and provides no evidence of active exploitation. CVSS indicates local access, low attack complexity, low privileges, and no user interaction. Although potential impact is high, the bundle does not establish practical exploit reliability or whether memory corruption can be converted into privilege escalation.
Researcher notes
The failure is a lifetime-management defect in cloned request bios: blk_complete_request() releases clone bios, but a stale rq->bio permits a second release during clone teardown. Upstream stable commits are supplied, but the bundle does not identify one universal fixed version, affected distributions, confirmed exploitation, or a CWE classification.
Mitigation direction
Apply the fixed kernel supplied by your Linux distribution or hardware platform vendor.
Prioritize updates on systems using dm-multipath, request-based device-mapper targets, or PCIe NVMe storage.
If patching is delayed, consult vendor guidance for supported configuration-specific mitigations.
Restrict local account access and monitor privileged workloads until affected hosts are remediated.
Validation and detection
Inventory running kernel builds and map them against distribution-specific CVE advisories.
Identify hosts using request-based device-mapper targets, dm-multipath, and PCIe NVMe namespaces.
Confirm installed kernels contain the applicable upstream stable fix or vendor backport.
Review kernel and storage logs for crashes or memory-safety warnings around device-mapper request completion.
Retest normal storage failover and multipath operations after updating.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43278 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.