CVE-2026-80837

Status: UPDATED  |  Advisory ID: CVE-2026-80837

Key Details

Affected Products, Subsystems & Sectors

What to Know

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:

<IRQ>

__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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References