Critical 9.8Published Jul 24, 2026

CVE-2026-64232block: recompute nr_integrity_segments in blk_insert_cloned_request

Updated under an hour ago (2026-10-19 08:50 UTC)

Does this affect you?

It affects Linux and 1 other product. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

Do this next

Start free and add your stack

Free account, 1 product

Every CVE for Linux

Exploited in the last 30 days

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.

CVSS: 9.8 CRITICAL (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Weakness (CWE): Not given
Known exploited: Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days): Not loaded for this CVE
Assigned by: Linux
NVD analysis: Analyzed
Record last updated: Oct 16, 2026
First seen by InfoSec Signals: Oct 9, 2026

Affected products

Affected products

Linux Linux linux:linux (from the name)	76c313f658d2752e8527610677164aa7094ef7a5 builds before 53a01bcc0242590eda4c452a5bd996f62457113b; from 76c313f658d2752e8527610677164aa7094ef7a5 before 0943f81e1b3176f27dbaf6db268fc69d8a94f0ba; from 76c313f658d2752e8527610677164aa7094ef7a5 before 42929c98d044f126508baf54a65b0f87f932fa75; 76c313f658d2752e8527610677164aa7094ef7a5 builds before 2c6e6a18a37b905cb584eb0dda3ae482162a81ca	CNA record
linux linux_kernel linux:linux_kernel	from 6.12 before 6.12.92; from 6.13 before 6.18.34; from 6.19 before 7.0.11; 7.1; 7.1; 7.1	NVD

References

https://git.kernel.org/stable/c/53a01bcc0242590eda4c452a5bd996f62457113bpatch
https://git.kernel.org/stable/c/0943f81e1b3176f27dbaf6db268fc69d8a94f0bapatch
https://git.kernel.org/stable/c/42929c98d044f126508baf54a65b0f87f932fa75patch
https://git.kernel.org/stable/c/2c6e6a18a37b905cb584eb0dda3ae482162a81capatch

The CVE record on cve.org NVD's entry

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.