CVE-2026-97530 in Linux
Résumé
par VulDB • 25/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
scsi: qla2xxx : Correction d'une boucle infinie (soft lockup) due à la poursuite de l'IOCB de continuation
qla27xx_copy_multiple_pkt() et qla27xx_copy_fpin_pkt() interrogent signature rsp_q->ring_ptr pour RESPONSE_PROCESSED (0xDEADDEAD), afin de déterminer si le prochain IOCB de continuation est arrivé, en bouclant sur cpu_relax() sans avancer l'anneau ni décrémenter le compteur d'entrées tant que ce n'est pas le cas. response_t::signature se trouve au décalage octet 60, mais un IOCB de continuation (sts_cont_entry_t / struct sts_cont_entry_ext) contient une charge utile brute FC frame à cet offset (data[56..59]). Une trame reçue dont les octets de la charge utile correspondent par hasard à 0xDEADDEAD est donc interprétée à tort comme « pas encore arrivée », et la boucle tourne indéfiniment dans un contexte d'interruption/DPC, provoquant un blocage logiciel du CPU (soft lockup).
L'interrogation est également inutile : les appelants de qla27xx_copy_multiple_pkt() (PT_LS4_UNSOL et le chemin purls NVMe) utilisent déjà qla_chk_cont_iocb_avail(), qui garantit que tous les IOCBs entry_count sont présents avant le début de la copie. L'assistant frère __qla_copy_purex_to_buffer() supprime déjà l'interrogation signature et s'appuie sur la garde entry_type == STATUS_CONT_TYPE à la place.
Supprimer l'attente active (busy-wait) basée sur la signature des deux assistants, en conservant la garde entry_type, et utiliser qla_chk_cont_iocb_avail() pour le chemin FPIN afin qu'il reporte et re-traite lors de la prochaine interruption une fois que tous les IOCBs de continuation sont arrivés, imitant ainsi les bras ELS_AUTH_ELS et PT_LS4_UNSOL. Avec cette modification, le champ signature n'est jamais lu sur un IOCB de continuation, éliminant ainsi le blocage dû à l'aliasing de la charge utile.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.