CVE-2026-64232: block: recompute nr_integrity_segments in blk_insert_cloned_request

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

block: recompute nrintegritysegments in blkinsertclonedrequest

blkinsertclonedrequest() already recomputes nrphyssegments 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 blkrqprepclone().

When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips

BUGON(segments > rq->nrintegritysegments);

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 queuemaxintegritysegments() 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.