CVE-2026-74748: netfilter: ipset: fix refcount race between list:set GC and swap
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix refcount race between list:set GC and swap
ipsetputbyindex() resolved the index to a set pointer under RCU, then took ipsetreflock in ipsetput() to decrement set->ref. ipsetswap() holds that same lock while swapping both the ipsetlist slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUGON(set->ref == 0). listsetgc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls listsetdel() -> ipsetputbyindex() while IPSETCMDSWAP runs on the referenced sets.
Resolve the index and decrement under ipsetreflock, as ipsetswap() already does, keeping the refcount tied to the index rather than to a stale set pointer.
kernel BUG at net/netfilter/ipset/ipsetcore.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ipsetputbyindex (net/netfilter/ipset/ipsetcore.c:870) Call Trace: <IRQ> listsetdel (net/netfilter/ipset/ipsetlistset.c:159) setcleanupentries (net/netfilter/ipset/ipsetlistset.c:181) listsetgc (net/netfilter/ipset/ipsetlistset.c:578) calltimerfn (kernel/time/timer.c:1748) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) runtimersoftirq (kernel/time/timer.c:2405) </IRQ> Kernel panic - not syncing: Fatal exception in interrupt
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (netfilter ipset)to a version that resolves this vulnerability.Patch netfilter: ipset: fix refcount race between list:set GC and swap - Compensating control
If possible, reduce exposure to the ipset list:set GC/swap race by disabling or limiting use of the list:set ipset type until the kernel patch is applied.
Event History
Frequently Asked Questions
Which systems are exposed to the race condition?
Systems using Linux kernel ipset list:set sets are exposed when garbage collection of an expiring list:set member can run concurrently with an IPSET_CMD_SWAP operation involving the referenced sets.
What conditions are required to trigger the failure?
A list:set member must expire so that list_set_gc() runs from timer softirq and calls ip_set_put_byindex(), while another operation performs IPSET_CMD_SWAP on the relevant sets. The nfnl mutex does not serialize timer softirq garbage collection against the swap operation.
How can I identify whether this issue has occurred?
The described failure produces a kernel BUG at net/netfilter/ipset/ip_set_core.c:685 and may appear as an invalid-opcode kernel Oops. The call trace includes ip_set_put_byindex(), list_set_del(), and execution from IRQ context.