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.