PT-2026-64347 · Linux · Linux

CVE-2026-64232

·

Publicado

2026-07-24

·

Atualizado

2026-07-24

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Identificadores relacionados

CVE-2026-64232

Produtos afetados

Linux