CVE-2026-64232

In the Linux kernel, the following vulnerability has been resolved:

block: recompute nrintegritysegments in blkinsertcloned_request

blkinsertclonedrequest() already recomputes nrphys_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 virtboundarymask, segboundarymask, or

maxsegmentsize than the top queue, in which case

blkrqcountintegritysg() against the bottom queue produces a

different count than the cached rq->nrintegritysegments inherited

from the source request by blkrqprep_clone().

When the cached count is lower than the bottom queue's actual count,

blkrqmapintegritysg() trips

BUGON(segments > rq->nrintegrity_segments);

on dispatch. The same families of stacked setups that motivated the

existing nrphyssegments recompute -- dm-multipath fanning out to

nvme-rdma in particular -- can produce this.

Mirror the nrphyssegments handling: when the request carries

integrity, recompute nrintegritysegments against the bottom queue

and reject the request if it exceeds the bottom queue's

maxintegritysegments. blkrqcountintegritysg() and

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