CVE-2026-64232

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: recompute nr_integrity_segments in blk_insert_cloned_request<br /> <br /> blk_insert_cloned_request() already recomputes nr_phys_segments<br /> against the bottom queue, because "the queue settings related to<br /> segment counting may differ from the original queue." The exact same<br /> reasoning applies to integrity segments: a stacked driver&amp;#39;s underlying<br /> queue can have tighter virt_boundary_mask, seg_boundary_mask, or<br /> max_segment_size than the top queue, in which case<br /> blk_rq_count_integrity_sg() against the bottom queue produces a<br /> different count than the cached rq-&gt;nr_integrity_segments inherited<br /> from the source request by blk_rq_prep_clone().<br /> <br /> When the cached count is lower than the bottom queue&amp;#39;s actual count,<br /> blk_rq_map_integrity_sg() trips<br /> <br /> BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);<br /> <br /> on dispatch. The same families of stacked setups that motivated the<br /> existing nr_phys_segments recompute -- dm-multipath fanning out to<br /> nvme-rdma in particular -- can produce this.<br /> <br /> Mirror the nr_phys_segments handling: when the request carries<br /> integrity, recompute nr_integrity_segments against the bottom queue<br /> and reject the request if it exceeds the bottom queue&amp;#39;s<br /> max_integrity_segments. blk_rq_count_integrity_sg() and<br /> queue_max_integrity_segments() are both already available via<br /> , which blk-mq.c includes.<br /> <br /> This closes a latent gap in the stacking contract and brings the<br /> integrity-segment accounting in line with the existing<br /> phys-segment accounting.