CVE-2026-64232 in Linux
Résumé
par VulDB • 24/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
block : recalculer nr_integrity_segments dans blk_insert_cloned_request
blk_insert_cloned_request() recalcule déjà nr_phys_segments par rapport à la file d'attente inférieure (bottom queue), car « les paramètres de la file d'attente liés au comptage des segments peuvent différer de ceux de la file d'origine ». Le même raisonnement s'applique aux segments d'intégrité : une file d'attente sous-jacente d'un pilote empilé peut présenter un virt_boundary_mask, un seg_boundary_mask ou un max_segment_size plus restrictifs que ceux de la file d'attente supérieure ; dans ce cas, blk_rq_count_integrity_sg() appliqué à la file inférieure produit un compte différent du rq->nr_integrity_segments mis en cache et hérité de la requête source par blk_rq_prep_clone().
Lorsque le compte mis en cache est inférieur au compte réel de la file d'attente inférieure, blk_rq_map_integrity_sg() déclenche :
BUG_ON(segments > rq->nr_integrity_segments);
lors de l'envoi (dispatch). Les mêmes familles de configurations empilées qui ont motivé le recalcul existant de nr_phys_segments -- en particulier dm-multipath diffusant vers nvme-rdma -- peuvent provoquer ce problème.
Mimictez la gestion de nr_phys_segments : lorsque la requête transporte des données d'intégrité, recalculez nr_integrity_segments par rapport à la file inférieure et rejetez la requête si elle dépasse le max_integrity_segments de cette dernière. blk_rq_count_integrity_sg() et queue_max_integrity_segments() sont déjà disponibles via <linux/blk-integrity.h>, inclus dans blk-mq.c.
Cela comble un écart latent dans le contrat d'empilement (stacking contract) et aligne la comptabilité des segments d'intégrité sur celle existante pour les segments physiques.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.