CVE-2026-80837

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux network filtering code can let specially crafted network traffic corrupt memory and crash the system or allow deeper attacks.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Moderate
Impact: Remote Code Execution
Component: OS kernel
Class: Race Condition
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Use-after-free race in nf_tables notification queuing: nft_quota_obj_eval from the packet path performs an unlocked list_add_tail on nft_net->notify_list while nf_tables_commit concurrently performs list_del + kfree_skb under commit_mutex, allowing a write through a freed sk_buff.

Why it matters to the business

Systems using nftables quota objects can experience kernel crashes or memory corruption when network traffic traverses affected rules, leading to denial of service or potential privilege escalation with high operational disruption on network infrastructure.

How an attack unfolds

An attacker sends packets that trigger nft_quota_obj_eval on a depleted quota object while simultaneously or concurrently a netlink batch commit drains the notify_list, racing the unlocked enqueue against the locked dequeue and kfree, resulting in a slab use-after-free write.

How to fix it

Apply the upstream fix that introduces nft_obj_notify_alloc and restores direct nfnetlink_send from the packet path; rebuild and deploy a patched kernel image; avoid nftables quota objects until updated.

How to confirm the fix worked

Verify the presence of the commit that splits nft_obj_notify, confirm nft_obj_notify no longer calls nft_notify_enqueue, and test that quota notifications are sent immediately without enqueueing from packet context.

Typical attack path

Configure nftables chain with quota object referenced by a rule
Deplete the quota object via legitimate or crafted traffic
Send UDP or other packets that hit the rule and call nft_quota_obj_eval under IRQ/softirq
Trigger a concurrent netlink transaction commit that drains notify_list
Trigger the list_add_tail write into the freed sk_buff

How to detect it

Search kernel logs for KASAN reports mentioning __nft_obj_notify, nft_quota_obj_eval, or skbuff_head_cache use-after-free; inspect netlink traffic for quota object notifications outside of commit batches; review audit logs for nftables rule changes coinciding with packet processing crashes.

What your security team should do

Prioritize kernel upgrade on all systems exposing nftables to untrusted traffic
Audit nftables rulesets for quota object usage and replace where possible
Monitor for KASAN or slab-use-after-free reports referencing __nft_obj_notify or nft_quota_obj_eval
Restrict unprivileged netlink access until patches are applied

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed