Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:16:53.770Z",
  "pubdate": "2026-08-26T15:16:53.770Z",
  "executiveSummary": "A race condition vulnerability exists in the Linux kernel's netfilter ipset subsystem, specifically involving the interaction between list:set garbage collection and set swapping operations.\nThe vulnerability is identified as a reference counting flaw where the set pointer is resolved under RCU but decremented outside of the synchronization lock, leading to potential inconsistency during concurrent operations.\nThis flaw can be triggered when a timer-based list_set_gc operation overlaps with an IPSET_CMD_SWAP command execution.\nSuccessful exploitation results in a kernel BUG_ON trigger, leading to a system crash and kernel panic. This represents a high-impact denial-of-service vulnerability.\nThe issue does not require complex authentication to trigger if an attacker can manipulate ipset configurations, though it typically manifests during specific concurrent timing conditions within the kernel networking stack.\nThe primary risk is the loss of system availability due to kernel panic in the timer softirq context.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper handling of set reference counters within 'net/netfilter/ipset/ip_set_core.c'. Specifically, the function '__ip_set_put_byindex()' performs an RCU-based resolution of a set pointer from an index, followed by a separate lock acquisition ('ip_set_ref_lock') in '__ip_set_put()' to decrement the reference count.\nThe 'ip_set_swap()' operation is designed to atomically swap both the 'ip_set_list' slots and the associated reference counters between two sets. Because 'ip_set_swap()' holds the 'ip_set_ref_lock', but the initial pointer dereference in '__ip_set_put_byindex()' occurs outside this lock's protection, a race condition window is created.\nIf 'ip_set_swap()' executes between the pointer dereference and the acquisition of the 'ip_set_ref_lock', the reference counter is no longer tied to the correct set pointer. Consequently, the kernel attempts to decrement a reference counter on a set whose reference has already been moved to a different index.\nThe issue is exacerbated by the fact that 'list_set_gc()' performs deletions from within a timer softirq context, which is not serialized by the 'nfnl' mutex against the 'IPSET_CMD_SWAP' operation. This allows for concurrent execution flows that violate the atomicity requirements of the reference counting logic.\nStep-by-step exploitation flow: 1) A 'list:set' member expires, triggering 'list_set_gc()'. 2) 'list_set_gc()' calls 'list_set_del()', which invokes '__ip_set_put_byindex()'. 3) The kernel resolves the set pointer via RCU. 4) Simultaneously, a user-space process initiates 'IPSET_CMD_SWAP'. 5) 'ip_set_swap()' acquires 'ip_set_ref_lock' and moves the set references. 6) The previously resolved set pointer in the GC path becomes stale. 7) '__ip_set_put()' acquires the lock and attempts to decrement a refcount on a stale or misaligned object, triggering a BUG_ON condition (set->ref == 0) and resulting in a kernel panic."
}