CVE-2026-80837 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
netfilter: nf_tables : ne pas mettre en file d'attente les notifications de l'objet « packet path »
Toutes les références fichier:ligne ci-dessous concernent la version v7.2-rc4 (ac5b0e5651b1). La trace a été capturée sur 7.2.0-rc6-kasan72rc6 (075b74841bd0), où les mêmes lignes s'appliquent.
nft_obj_notify() est exporté et atteint depuis le packet path. Son seul appelant dans l'arborescence du code source est nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), qui notifie avec GFP_ATOMIC lors de l'évaluation d'une règle pour un paquet transitif, sans détenir de mutex.
Depuis le commit 67cc570edaa0 (« netfilter: nf_tables : fusionner plusieurs notifications en une seule skbuff »), cette notification n'est plus envoyée immédiatement. __nft_obj_notify() la met en file d'attente sur notify_list via nft_net->notify_list par l'intermédiaire de nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), qui est un simple list_add_tail(). La liste notify_list ne possède pas sa propre verrouillage ; elle est sérialisée par commit_mutex : les six autres sites d'enfilement s'exécutent tous dans le cadre d'une transaction netlink, et la vidange effectuée dans nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) réalise un list_del() + kfree_skb() depuis nf_tables_commit() avec commit_mutex détenu.
L'envoi de paquets à travers une chaîne qui fait référence à un objet quota épuisé crée donc une condition de course entre un list_add_tail() non verrouillé et un list_del() + kfree_skb() sur un autre CPU. L'instruction WRITE_ONCE(prev->next, new) dans __list_add() écrit alors dans un sk_buff qui a déjà été libéré :
BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto
Alloué par la tâche 77 : __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain
Libéré par la tâche 79 : nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg
L'adresse buggée appartient au cache skbuff_head_cache de taille 232.
La mise en file d'attente depuis le packet path est incorrecte, même en laissant la condition de course de côté : notify_list n'est vidangée que par nft_commit_notify() depuis nf_tables_commit() (:11185), donc une notification enfilée en dehors d'une transaction ne sera pas envoyée jusqu'à ce qu'un lot netlink ultérieur soit validé, si cela arrive un jour.
L'argument gfp que prend encore nft_obj_notify() est un vestige du comportement pré-67cc570edaa0, où ce chemin appelait directement nfnetlink_send(). Rétablissons ce comportement : séparez la construction du message dans nft_obj_notify_alloc() et laissez chaque appelant décider quoi faire avec le skb. nft_obj_notify(), l'exporté atteint depuis le packet path, l'envoie immédiatement ; nf_tables_obj_notify(), qui s'exécute sous commit_mutex, continue de le mettre en file d'attente, afin que les notifications de transaction restent toujours fusionnées.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.