https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 00:47:55 +0000 https://vulnerability.circl.lu/vuln/cve-2026-64232 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>block: recompute nr_integrity_segments in blk_insert_cloned_request</p> <p>blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because &#34;the queue settings related to segment counting may differ from the original queue.&#34; The exact same reasoning applies to integrity segments: a stacked driver&#39;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-&gt;nr_integrity_segments inherited from the source request by blk_rq_prep_clone().</p> <p>When the cached count is lower than the bottom queue&#39;s actual count, blk_rq_map_integrity_sg() trips</p> <p>BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);</p> <p>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.</p> <p>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&#39;s max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via &lt;linux/blk-integrity.h&gt;, which blk-mq.c includes.</p> <p>This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with t…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>block: recompute nr_integrity_segments in blk_insert_cloned_request</p> <p>blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because &#34;the queue settings related to segment counting may differ from the original queue.&#34; The exact same reasoning applies to integrity segments: a stacked driver&#39;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-&gt;nr_integrity_segments inherited from the source request by blk_rq_prep_clone().</p> <p>When the cached count is lower than the bottom queue&#39;s actual count, blk_rq_map_integrity_sg() trips</p> <p>BUG_ON(segments &gt; rq-&gt;nr_integrity_segments);</p> <p>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.</p> <p>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&#39;s max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via &lt;linux/blk-integrity.h&gt;, which blk-mq.c includes.</p> <p>This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with t…</p> https://vulnerability.circl.lu/vuln/cve-2026-64232