CVE-2026-80787 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
nvmet: pci-epf : correction d'un use-after-free dans nvmet_pci_epf_exec_iod_work()
La fonction nvmet_pci_epf_exec_iod_work() soumet une commande E/S avec req->execute(), puis attend que la commande se termine et transfère les données vers l'hôte. Cette attente n'est pas nécessaire pour les commandes qui ne transfèrent pas de données du périphérique vers l'hôte. Pour déterminer si cette attente est requise, le code lit iod->data_len et iod->dma_dir après avoir appelé req->execute().
Cependant, une fois que req->execute() a été appelée, la commande peut se terminer de manière asynchrone sur un autre processeur (CPU). Pour les commandes qui ne nécessitent pas de transfert de données du périphérique vers l'hôte, nvmet_pci_epf_queue_response() appelle directement nvmet_pci_epf_complete_iod(), ce qui peut libérer iod avant qu'il n'ait lu iod->data_len et iod->dma_dir, entraînant un use-after-free détecté par KFENCE :
BUG: KFENCE: use-after-free read in nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf]
Use-after-free read at 0x00000000fdfa6d03 (in kfence-#63): nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf]
process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20
kfence-#63: 0x00000000e3de0e71-0x00000000c938ad62, size=712, cache=kmalloc-1k
alloué par la tâche 10 sur le cpu 0 à 73.995480s (il y a 0.005122s) : mempool_kmalloc+0x1c/0x28 mempool_alloc_noprof+0x40/0x9c nvmet_pci_epf_poll_sqs_work+0xd4/0x344 [nvmet_pci_epf]
process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20
libéré par la tâche 131 sur le cpu 3 à 73.995521s (il y a 0.008385s) : mempool_kfree+0x10/0x20 mempool_free+0x44/0x64 nvmet_pci_epf_free_iod+0x88/0x98 [nvmet_pci_epf]
nvmet_pci_epf_cq_work+0xfc/0x280 [nvmet_pci_epf]
process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20
Cette correction consiste à accéder à iod->data_len et iod->dma_dir avant d'appeler req->execute(). Les autres accès aux membres de
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.