CVE-2026-64113 in Linux
Résumé
par VulDB • 19/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ixgbevf : correction d'un use-after-free dans l'élagage des sources de multicast VEPA
La fonction `ixgbevf_clean_rx_irq()` élimine les trames dont l'adresse MAC source correspond à l'adresse propre du VF (contournement pour le multicast VEPA) en libérant le skb et en passant au descripteur suivant :
dev_kfree_skb_irq(skb); continue;
Le pointeur `skb` est déclaré en dehors de la boucle while et persiste entre les itérations. Étant donné que l'instruction `continue` saute la réinitialisation « `skb = NULL` » située au bas de la boucle, l'itération suivante emprunte le chemin « else if (skb) » et appelle `ixgbevf_add_rx_frag()` sur un skb déjà libéré, déréférençant ainsi `skb_shinfo(skb)->nr_frags`, ce qui constitue un use-after-free dans le contexte du softirq NAPI.
Le pilote frère iavf gère correctement cette situation en initialisant à NULL le pointeur avant de continuer. Appliquez ici la même approche.
Je ne dispose pas de matériel ixgbevf ; le bug a été détecté par analyse statique (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, corroboration multi-outils avec le score le plus élevé dans l'analyse). Le UAF a été confirmé sous KASAN en chargeant un module de test qui reproduit exactement ce motif de code (allocation d'un skb, kfree_skb, puis lecture de `skb_shinfo(skb)->nr_frags`) :
BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)
QEMU émule igb (82576) mais pas ixgbe (82599), et le pilote VF igbvf n'inclut pas le chemin d'élagage des sources VEPA, de sorte qu'une reproduction complète bout-en-bout avec du matériel simulé n'était pas possible.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.