CVE-2026-74748 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix refcount race between list:set GC and swap
__ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list 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 BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets.
Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer.
kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: <IRQ> list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) </IRQ> Kernel panic - not syncing: Fatal exception in interrupt
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel vulnerability identified involves a critical reference count race condition within the netfilter ipset subsystem, specifically affecting list-based sets during garbage collection and set swapping operations. This flaw arises from an inconsistent locking strategy when managing object lifecycles across concurrent execution contexts. The core issue lies in how __ip_set_put_byindex() resolves a set index to a pointer under Read-Copy-Update (RCU) protection before attempting to acquire the ip_set_ref_lock to decrement the reference counter. Meanwhile, the ip_set_swap function holds this same lock while simultaneously swapping both the slots within the ip_set_list and adjusting the reference counters of the two involved sets. This creates a window where the swap operation can interleave between the initial dereference in __ip_set_put_byindex() and its subsequent attempt to acquire the refcount lock. Consequently, the caller may end up decrementing the reference count of a set that has already been moved to a different index or whose ownership has shifted due to the ongoing swap. This race condition leads to an incorrect state where the reference counter reaches zero unexpectedly, triggering a BUG_ON assertion and resulting in a kernel panic with a fatal exception in interrupt context.
The operational impact of this vulnerability is severe, as it can lead to system instability and denial of service through kernel crashes. The error manifests as a kernel bug at net/netfilter/ipset/ip_set_core.c:685, accompanied by an invalid opcode oops and KASAN (Kernel Address Sanitizer) reports indicating memory safety violations. The call trace reveals that the crash is initiated from list_set_gc(), which runs in timer softirq context during garbage collection of expired list:set members. This function calls list_set_del() followed by ip_set_put_byindex(). Because this execution path operates within a softirq handler, it is not serialized against IPSET_CMD_SWAP operations handled via netlink sockets under the nfnl mutex. The lack of synchronization between these two distinct paths allows the race condition to occur, causing the kernel to panic with Fatal exception in interrupt. This affects systems relying on dynamic ipset management where sets are frequently swapped or garbage collected while other processes attempt to release references to those sets.
From a technical perspective, this vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The root cause is the failure to maintain atomicity between resource lookup and reference count modification when shared locks are involved in concurrent state transitions. In terms of MITRE ATT&CK framework, this aligns with T1499: Endpoint Denial of Service, as an attacker could potentially trigger rapid set swaps and garbage collection cycles to induce a kernel panic, thereby disrupting system availability. The vulnerability highlights the complexity of managing reference counting in high-concurrency environments where RCU is used for read-side safety but must be carefully coordinated with write-side locking mechanisms like ip_set_ref_lock.
The resolution involves restructuring __ip_set_put_byindex() to resolve the index and decrement the reference count while holding the ip_set_ref_lock, mirroring the approach already implemented in ip_set_swap(). This ensures that the refcount manipulation is strictly tied to the current state of the set index at the time of access, preventing operations on stale pointers or incorrect sets. By acquiring the lock before dereferencing and modifying the reference count, the kernel guarantees mutual exclusion between garbage collection threads and swap operations. Administrators should apply the relevant kernel patch that addresses this race condition in net/netfilter/ipset/ip_set_core.c to restore stability. Monitoring for similar patterns of inconsistent locking around RCU-protected data structures is recommended to prevent analogous vulnerabilities in other subsystems where reference counting interacts with concurrent state changes.