CVE-2026-97609: netfilter: cttimeout: prevent UAF during module unload
In the Linux kernel, the following vulnerability has been resolved:
netfilter: cttimeout: prevent UAF during module unload
nfctsettimeout() protects the timeout hook dereference and policy lookup with rcureadlock(). cttimeoutexit(), however, unregisters the per-net operations before it clears the hook.
This allows the following interleaving:
CPU 0 CPU 1 cttimeoutexit() nfctsettimeout() unregisterpernetsubsys() rcureadlock() kfree(pernet) h = nfcttimeouthook h->timeoutfindget() nfcttimeoutpernet()
The hook still points to ctnltimeoutfindget() when CPU 1 looks up the already freed per-net timeout list. KASAN reported:
BUG: KASAN: slab-use-after-free in ctnltimeoutfindget Read of size 8 by task poc/90 Call Trace: ctnltimeoutfindget+0x271/0x2a0 [nfnetlinkcttimeout] nfctsettimeout+0x7b/0x3c0 xtcttgcheck+0x724/0xb20 xtchecktarget+0x234/0xa90 doiptsetctl+0x570/0x1270 Allocated by task 89: kmallocnoprof+0x16e/0x460 opsinit+0x6d/0x420 registerpernetoperations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 opsundolist+0x3d4/0x730 unregisterpernetoperations+0x232/0x490 unregisterpernetsubsys+0x1c/0x30 cttimeoutexit+0x52/0x970 [nfnetlinkcttimeout]
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the cttimeout module unload path, clear the timeout hook before unregistering per-net operations, protect the timeout-hook dereference and policy lookup with rcu_read_lock(), and wait for existing readers to finish before freeing per-net timeout storage.
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
The race requires cttimeout module exit to unregister per-network operations and free the per-net timeout list while another CPU executes nf_ct_set_timeout(). In the reported path, the concurrent operation reaches nf_ct_set_timeout() through xt_ct_tg_check() during an iptables control operation.
What component is involved in the vulnerable lookup?
The stale hook can still point to ctnl_timeout_find_get() from the nfnetlink_cttimeout module after the per-net timeout data has been freed. The resulting access occurs when that function looks up the freed per-net timeout list.
How might this issue appear during testing or incident analysis?
KASAN can report a slab-use-after-free in ctnl_timeout_find_get(), with nf_ct_set_timeout(), xt_ct_tg_check(), xt_check_target(), and do_ipt_set_ctl() in the call trace. The report identifies an 8-byte read from freed memory.