PT-2026-85715 · Linux · Linux

CVE-2026-80837

·

Publicado

2026-09-04

·

Atualizado

2026-09-04

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf tables: don't queue packet path object notifications
All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply.
nft obj notify() is exported and reached from the packet path. Its only in-tree caller is nft quota obj eval() (net/netfilter/nft quota.c:68), which notifies with GFP ATOMIC while evaluating a rule for a transiting packet, holding no mutex.
Since commit 67cc570edaa0 ("netfilter: nf tables: coalesce multiple notifications into one skbuff") that notification is no longer sent immediately. nft obj notify() queues it onto nft net->notify list via nft notify enqueue() (net/netfilter/nf tables api.c:1211), which is a bare list add tail(). notify list has no lock of its own (include/net/netfilter/nf tables.h:1951), it is serialised by commit mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft commit notify() (net/netfilter/nf tables api.c:10746) does list del() + kfree skb() from nf tables commit() with commit mutex held.
Sending packets through a chain that references a depleted quota object therefore races an unlocked list add tail() against list del() + kfree skb() on another CPU. The WRITE ONCE(prev->next, new) in list add() then stores through an sk buff that has already been freed:
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
Allocated by task 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
Freed by task 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
The buggy address belongs to the cache skbuff head cache of size 232
Queueing from the packet path is wrong even leaving the race aside: notify list is only drained by nft commit notify() from nf tables commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does.
The gfp argument that nft obj notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink send() directly. Restore that: split the message construction out into nft obj notify alloc() and let each caller decide what to do with the skb. nft obj notify(), the exported one reached from the packet path, sends it straight away; nf tables obj notify(), which runs under commit mutex, keeps queueing it, so transaction notifications are still coalesced.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

CVE-2026-80837

Produtos afetados

Linux