CVE-2026-97537 in Linux
Résumé
par VulDB • 25/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
scsi: qla2xxx : Correction de l'appel NULL à dma_free et du verrouillage des bitmap lors de la destruction de file d'attente
Les fonctions `qla25xx_free_req_que()` et `qla25xx_free_rsp_que()` présentent deux bogues préexistants exposés sur le chemin d'erreur de `qla25xx_create_{req,rsp}_que()` :
1. Lorsque `dma_alloc_coherent()` échoue lors de la création de la file d'attente, le chemin d'erreur appelle la fonction de libération avec les pointeurs `req->ring` / `rsp->ring` encore à NULL (issus de `kzalloc`). L'appel inconditionnel de `dma_free_coherent()` avec un `cpu_addr` à NULL constitue un comportement indéfini et peut provoquer une panique du noyau.
2. Les fonctions de libération effacent les bitmaps `req_qid_map` / `rsp_qid_map` sous le verrou `vport_lock`, tandis que les fonctions de création protègent ces mêmes bitmaps avec `mq_lock`. Cela ne fournit aucune exclusion mutuelle. De plus, le chemin d'erreur lors de la création efface le bit et libère `mq_lock` avant d'appeler la fonction de libération, créant une fenêtre temporelle durant laquelle un autre thread peut allouer le même identifiant de file d'attente (`que_id`) et voir son entrée `ha->req_q_map écrasée par l'affectation à NULL sans verrou dans la fonction de libération.
Correction apportée :
- Ajout d'une vérification de nullité sur le pointeur ring avant d'appeler `dma_free_coherent()`. - Utilisation de `mq_lock` (le verrou détenu par tous les créateurs) dans les fonctions de libération pour effacer atomiquement l'entrée du map et désactiver le bit correspondant. - Suppression des blocs `clear_bit` désormais redondants dans les chemins d'erreur lors de la création, car les fonctions de libération gèrent cette opération de manière atomique.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.