Skip to main content
VulnerabilityPublished Updated

CVE-2026-43278: Linux kernel · dm: clear cloned request bio pointer when last clone bio completes

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in fb8a6c18fb9a6561f7a15b58b272442b77a242dd : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 1% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in fb8a6c18fb9a6561f7a15b58b272442b77a242dd, e2e738e8dfbbf83bd2bae0467ec4420cc52da42a, b1c1a2637ebd675aa2d71fee8c70da8791d73850 +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 6 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < fb8a6c18fb9a6561f7a15b58b272442b77a242dd
Fixed in
  • fb8a6c18fb9a6561f7a15b58b272442b77a242dd
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < e2e738e8dfbbf83bd2bae0467ec4420cc52da42a
Fixed in
  • e2e738e8dfbbf83bd2bae0467ec4420cc52da42a
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < b1c1a2637ebd675aa2d71fee8c70da8791d73850
Fixed in
  • b1c1a2637ebd675aa2d71fee8c70da8791d73850
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < 83d72091804600ead96dc9e9f518ea56cb4942f6
Fixed in
  • 83d72091804600ead96dc9e9f518ea56cb4942f6
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < 8d9ddad561136f7e6a9346767bf97b4d79e38e67
Fixed in
  • 8d9ddad561136f7e6a9346767bf97b4d79e38e67
LinuxLinuxAffected
  • ≥ ab3e1d3bbab9e973aeb4dd4603251578658a47ff, < 7daf279c674d515fb22a727a7bbc92aeb35c5442
Fixed in
  • 7daf279c674d515fb22a727a7bbc92aeb35c5442

Description

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.

References

Community reviews

Loading reviews…