Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-09-25T11:17:14.870Z",
  "pubdate": "2026-09-25T11:17:14.870Z",
  "executiveSummary": "A race condition vulnerability exists in the Linux kernel's netfilter (nf_log) subsystem, specifically concerning the interaction between per-network namespace teardown and global logger backend unregistration.\nThe vulnerability allows for a Use-After-Free (UAF) scenario where a global logger can be rebound to a network namespace after the namespace's local state has been cleared but before the logger itself has been unregistered.\nThis flaw impacts both nf_log_syslog and nfnetlink_log. An attacker capable of interacting with sysctl or netlink interfaces could potentially trigger the use of stale memory pointers, leading to kernel instability, denial of service, or potentially arbitrary code execution depending on the state of the freed memory.\nExploitation requires the ability to trigger a module exit sequence simultaneously with a logger binding operation, creating a tight window of opportunity for the kernel to dereference a dangling pointer.",
  "technicalDetails": "The root cause of this vulnerability is an improper ordering of teardown operations within the Linux kernel's netfilter logging subsystem. Specifically, the system performs per-network namespace (per-net) teardown via unregister_pernet_subsys() before unregistering the global logger backends via nf_log_unregister().\nDuring the execution of unregister_pernet_subsys(), the kernel calls nf_log_unset(), which clears the net->nf.nf_loggers[pf] pointer for a given namespace. However, because the global logger backend remains registered, a separate thread can acquire the nf_log_mutex and rebind the logger to the namespace by writing to the loggers[][] table before the module exit path completes.\nThe attack flow follows a race condition pattern: 1) CPU 0 executes the module exit sequence, entering unregister_pernet_subsys() to nullify the per-net logger configuration. 2) Before CPU 0 completes, CPU 1 acquires the nf_log_mutex and successfully rebinds a logger to the namespace. 3) CPU 0 proceeds to nf_log_unregister(), which clears the global backend and invokes synchronize_rcu(), subsequently triggering the freeing of the backend memory associated with the logger.\nBecause the logger was rebound on CPU 1, the network namespace still contains a reference to the now-freed backend memory. Subsequent operations—such as a sysctl read or a packet logging event—will attempt to dereference this stale pointer. This leads to a kernel Use-After-Free condition.\nThis vulnerability is persistent across systems where the netfilter logging modules are dynamically loaded and unloaded. The impact is significant as it affects core kernel memory management within the networking stack. Access to the system is required to interact with sysctl or netlink, and the vulnerability is constrained by the necessity of timing the race condition accurately to ensure the pointer is dereferenced after the memory has been released by the slab allocator."
}