Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: prevent UAF during module unload nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get() nfct_timeout_pernet() The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported: BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get Read of size 8 by task poc/90 Call Trace: ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout] nf_ct_set_timeout+0x7b/0x3c0 xt_ct_tg_check+0x724/0xb20 xt_check_target+0x234/0xa90 do_ipt_set_ctl+0x570/0x1270 Allocated by task 89: __kmalloc_noprof+0x16e/0x460 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 ops_undo_list+0x3d4/0x730 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout] Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-09-25T11:17:14.987Z",
  "pubdate": "2026-09-25T11:17:14.987Z",
  "executiveSummary": "A use-after-free (UAF) vulnerability exists in the Linux kernel's netfilter cttimeout module, specifically within the interaction between per-network namespace operations and the timeout hook mechanism.\nThe vulnerability occurs because the kernel unregisters per-network namespace operations before clearing the global timeout hook, leading to a race condition.\nAn attacker capable of triggering module unloading or concurrent netfilter configuration operations can exploit this flaw to cause a kernel panic or potentially execute arbitrary code.\nThe primary risk involves memory corruption resulting from an RCU-protected reader accessing deallocated per-net storage.\nSuccessful exploitation requires local access to the system, typically requiring privileges sufficient to configure netfilter or trigger module operations.",
  "technicalDetails": "The vulnerability resides in the nf_ct_set_timeout function and the cttimeout_exit cleanup routine within the netfilter cttimeout module. The root cause is an improper synchronization sequence during the module teardown process. Specifically, the cttimeout_exit function calls unregister_pernet_subsys() before explicitly clearing the nf_ct_timeout_hook.\nThe nf_ct_set_timeout function relies on RCU (Read-Copy-Update) semantics, utilizing rcu_read_lock() to protect the dereferencing of the timeout hook and subsequent policy lookup. However, if the module unloading process proceeds to free the per-network namespace data structure via unregister_pernet_subsys while a concurrent process is performing a lookup, a race condition occurs.\nAttack Flow: 1) CPU 0 executes cttimeout_exit, triggering unregister_pernet_subsys, which subsequently calls kfree on the per-net data structures. 2) Simultaneously, CPU 1 executes nf_ct_set_timeout, acquiring the RCU read lock. 3) CPU 1 retrieves the pointer to nf_ct_timeout_hook, which still points to ctnl_timeout_find_get because the cleanup routine has not yet cleared it. 4) CPU 1 proceeds to call ctnl_timeout_find_get, which attempts to dereference the now-freed per-net memory allocated by the module. 5) This results in a KASAN-detected use-after-free read operation.\nThis vulnerability highlights a critical failure in the lifecycle management of kernel pointers. Because the timeout hook is not zeroed and synchronized with a synchronize_rcu() call prior to the destruction of the underlying per-net storage, any pending read operations that were already inside the RCU read-side critical section are left with a dangling pointer.\nThe impact of this vulnerability is significant, as it leads to memory corruption in kernel space. Depending on the memory layout and the kernel's ability to handle the fault, this will likely result in an immediate kernel panic (denial of service). In more sophisticated scenarios, if an attacker can control the contents of the newly allocated slab memory that replaces the freed object, they could potentially influence control flow or escalate privileges, although this is inherently difficult given the race condition requirements."
}