CVE-2026-74656 in Linux
Résumé
par VulDB • 23/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ipv4 : correction d'un use-after-free dans fib_nhc_update_mtu()
fib_nhc_update_mtu() parcourt la table des exceptions de next hop sous RTNL, mais RTNL ne sérialise pas ce parcours avec les mises à jour des exceptions PMTU. Le parcours utilise rcu_dereference_protected() avec une condition constante vraie sans détenir fnhe_lock.
L'entrelacement suivant peut donc se produire :
CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) <état quiescent> accès à fnhe après la période de grâce
KASAN a signalé :
BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120
Le même parcours met à jour fnhe_pmtu et fnhe_mtu_locked. Ces champs forment une paire et d'autres écritures les sérialisent avec fnhe_lock. RCU seul empêche la récupération, mais permettrait toujours aux writers concurrents de laisser une paire mixte.
Parcourez le tableau sous RCU et acquérez fnhe_lock uniquement lors de la mise à jour de chaque exception. RCU maintient l'entrée actuelle en vie tandis que la section critique courte sérialise ses champs PMTU appariés. Cela évite de détenir le verrou global tout en analysant les 2048 buckets pour chaque next hop.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.