PT-2026-64347 · Linux · Linux
CVE-2026-64232
·
Published
2026-07-24
·
Updated
2026-07-24
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux