CVE-2026-80837 in Linux
Summary
by MITRE • 09/04/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Linux kernel involves a race condition within the netfilter subsystem, specifically affecting the nftables quota object notification mechanism. This issue arises from an improper interaction between packet processing paths and administrative commit operations. The core flaw lies in how notifications for quota objects are queued when evaluated during active packet traversal versus when they are processed during configuration commits. A security researcher or attacker with network access can trigger this race condition by sending packets through a chain that references a depleted quota object, leading to memory corruption and potential system instability.
The technical root cause is rooted in the concurrency model of the nf_tables subsystem. The function nft_obj_notify() was modified in commit 67cc570edaa0 to coalesce multiple notifications into a single socket buffer for efficiency. This change introduced a notification list, notify_list, which is serialized by holding the commit_mutex during netlink transactions. However, the specific caller nft_quota_obj_eval(), located in net/netfilter/nft_quota.c, invokes this notification function from within the packet path while evaluating rules for transiting packets. Crucially, this evaluation occurs without holding any mutex and uses GFP_ATOMIC allocation flags because it operates in an atomic context where sleeping is not permitted.
This creates a critical race condition between two distinct execution contexts on different CPUs. On one CPU, nft_quota_obj_eval() attempts to enqueue a notification onto the notify_list using list_add_tail(). Since this operation happens outside of a transaction and without holding commit_mutex, it bypasses the serialization mechanism intended for that list. Simultaneously, on another CPU, nf_tables_commit() executes as part of a netlink batch processing sequence. This function holds the commit_mutex and drains the same notify_list by performing list_del operations followed by kfree_skb to free the socket buffers. The lack of synchronization means that nft_quota_obj_eval may attempt to add an element to a list while another CPU is actively removing elements from it, leading to use-after-free conditions where pointers are dereferenced after memory has been released.
The operational impact of this vulnerability includes kernel crashes and potential privilege escalation vectors through heap corruption. The KASAN trace confirms a slab-use-after-free error occurring in __nft_obj_notify when writing to the next pointer of an sk_buff that has already been freed by nf_tables_commit. This results in undefined behavior, typically manifesting as a system panic or oops due to invalid memory access at addresses belonging to the skbuff_head_cache. Beyond immediate stability issues, such heap corruption can potentially be exploited to execute arbitrary code if the attacker can control the contents of the freed memory region and manipulate subsequent allocations, although the primary observed impact is denial of service via kernel crash.
From a standards perspective, this vulnerability maps directly to CWE-416: Use After Free, as it involves accessing memory that has been deallocated due to improper synchronization between concurrent threads or processes. It also relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), specifically involving a shared data structure (the notify_list) accessed without adequate locking mechanisms in all code paths. In the context of MITRE ATT&CK, this could be categorized under T1059: Command and Scripting Interpreter if exploited for further system compromise, or more broadly as part of infrastructure exploitation techniques that target kernel-level components to disrupt service availability.
The mitigation strategy implemented involves restructuring how notifications are handled based on their execution context. The fix splits the notification logic into two distinct functions. A new internal function, nft_obj_notify_alloc(), is introduced to handle message construction without immediate sending or queueing. The exported function nft_obj_notify() is modified to send the notification immediately using nfnetlink_send when called from packet paths like nft_quota_obj_eval, thereby avoiding the shared list entirely in atomic contexts. Meanwhile, a separate internal function, nf_tables_obj_notify(), retains the original queuing behavior for use within netlink transactions where commit_mutex protects the notify_list. This ensures that notifications generated during administrative changes are still coalesced efficiently without introducing race conditions against packet processing threads.
Administrators and developers should ensure their systems are updated with kernel versions containing this fix, which addresses the concurrency flaw in nf_tables notification handling. For environments running vulnerable kernels, mitigating factors include restricting access to netlink interfaces that trigger quota updates and monitoring for unusual network traffic patterns involving high-volume UDP or IP packets targeting specific firewall chains. However, since the vulnerability is triggered by legitimate packet processing logic rather than malformed input alone, complete patching remains the only effective remediation. The fix restores correct memory management practices by ensuring that shared resources are either protected by locks when modified concurrently or isolated from concurrent access entirely through architectural separation of concerns between atomic and transactional code paths.