CVE-2026-72323: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()
In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: Fix potential UAF in igmpgqstarttimer()
A race condition exists between device teardown (inetdevdestroy) and incoming IGMP query processing (igmprcv), leading to a Use-After-Free in the IGMP timer callback.
During device destruction, inetdevdestroy() drops the primary reference to indevice, which can drop its refcount to 0. The actual freeing of indevice memory is deferred via RCU (using callrcu()).
Concurrently, igmprcv() runs under RCU read lock and obtains the indevice pointer. Because the memory is RCU-protected, CPU-0 can safely dereference indevice even if its refcount has hit 0.
However, if CPU-0 calls igmpgqstarttimer() and re-arms the timer, it attempts to acquire a reference using indevhold(). This increments the refcount from 0 to 1, triggering a "refcountt: addition on 0" warning. Since the indevice memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic.
Fix this by using refcountincnotzero() (via a new helper indevholdsafe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not arm the timer.
A similar issue in IPv6 MLD is fixed in a subsequent patch.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix for the UAF in igmp_gq_start_timer() by preventing the IGMP timer callback from acquiring a reference to the in_device via in_dev_hold_safe() (i.e., use refcount_inc_not_zero() to avoid taking a reference when the in_device refcount has hit 0). This ensures the timer is not re-armed when refcount is 0.
Linux kernel (ipv4: igmp) Use refcount_inc_not_zero() via new helper in_dev_hold_safe() = N/A