PT-2026-85715 · Linux · Linux
CVE-2026-80837
·
Published
2026-09-04
·
Updated
2026-09-04
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux