CVE-2026-64232
CVE-2026-64232 is a critical-severity vulnerability in Linux Linux Kernel with a CVSS 3.x base score of 9.8. It is not currently listed as actively exploited by CISA, and its EPSS exploit-prediction score is low.
Key facts
- Severity: Critical (CVSS 3.x base score 9.8)
- EPSS exploit prediction: 0% (38th percentile)
- Actively exploited: Not listed in CISA KEV
- Affected product: Linux Linux Kernel
- Published:
- Last modified:
Description
In the Linux kernel, the following vulnerability has been resolved: block: recompute nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
Frequently asked questions
- What is CVE-2026-64232?
- In the Linux kernel, the following vulnerability has been resolved: block: recompute nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
- How severe is CVE-2026-64232?
- CVE-2026-64232 has a CVSS 3.x base score of 9.8, rated critical severity. It is exploitable over network with low attack complexity, requires no privileges and no user interaction. Impact on confidentiality is high, integrity high, and availability high.
- Is CVE-2026-64232 being actively exploited?
- It is not currently listed in CISA's KEV catalog. Its EPSS exploit-prediction score is 0% (38th percentile), an estimate of the probability of exploitation in the next 30 days.
- What products are affected by CVE-2026-64232?
- CVE-2026-64232 primarily affects Linux Linux Kernel. In total, 4 product configurations (CPEs) are listed as vulnerable; see the affected-products list for the exact versions.
- How do I fix CVE-2026-64232?
- Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround. Given its critical severity, prioritise patching exposed systems.
- When was CVE-2026-64232 published?
- CVE-2026-64232 was published on 2026-07-24 and last updated on 2026-08-12.
References
- https://git.kernel.org/stable/c/0943f81e1b3176f27dbaf6db268fc69d8a94f0ba
- https://git.kernel.org/stable/c/2c6e6a18a37b905cb584eb0dda3ae482162a81ca
- https://git.kernel.org/stable/c/42929c98d044f126508baf54a65b0f87f932fa75
- https://git.kernel.org/stable/c/53a01bcc0242590eda4c452a5bd996f62457113b
Affected products (4)
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
- cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
More vulnerabilities in Linux Linux Kernel
- CVE-2026-63795 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error…
- CVE-2025-38429 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after…
- CVE-2025-22021 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6…
- CVE-2025-21663 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwmac-tegra: Read iommu stream id…
- CVE-2024-56719 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing…
- CVE-2024-44984 — Critical (CVSS 10.0): In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix double DMA unmapping for…