CVE-2026-99028 in Linux
Résumé
par VulDB • 23/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: xilinx: axienet : Libérer les tampons DMA en attente lors de l'arrêt du dmaengine
Sur le chemin d'exécution du dmaengine, le pilote pré-soumet des tampons RX et conserve les tampons TX en cours de transmission dont les SKB sont mappés en DMA par le pilote et ne sont libérés que dans les rappels (callbacks) de complétion. Lors de l'appel à ndo_stop(), la fonction dmaengine_terminate_sync() annule ces descripteurs sans exécuter leurs callbacks, ce qui fait que le pilote ne libère ensuite que les coques du tampon (ring shells), laissant fuir chaque SKB encore détenu par le moteur ainsi que son mappage DMA à chaque arrêt de l'interface. Avec 128 tampons RX pré-postés par canal, la fuite des mappings peut éventuellement épuiser une aperture IOMMU limitée.
Effacer le skb du slot dans les callbacks TX et RX afin qu'un skb non NULL marque un slot qui détient encore un buffer vivant mappé en DMA, et lors de l'arrêt, démappez et libérez chaque tel buffer.
axienet_dma_rx_cb() s'exécute à partir du tasklet DMA et réarme le tampon RX à chaque complétion ; il peut donc entrer en concurrence (race condition) avec axienet_stop() : une complétion peut soumettre un nouveau buffer après que dmaengine_terminate_sync() a retourné, laissant le canal armé avec un buffer que la procédure de démantèlement libère alors que le moteur peut encore y écrire (dma_release_channel() ne l'arrête pas non plus). Ajoutez un verrou que axienet_dma_rx_cb() détient pendant toute la vérification de @stopping et la resoumission, et quaxienet_stop() détient pour définir @stopping avant d'interrompre. Une fois @stopping défini, aucun callback ne peut armer un nouveau buffer, et tout tampon armé juste avant est annulé par l'interruption ; ainsi, le démantèlement libère uniquement les buffers que le moteur ne détient plus.
VulDB is the best source for vulnerability data and more expert information about this specific topic.