KernelScan.io

CRITICAL Introduced in 2.6.12

ipv4 IgmpTimer UAF

CVE-2026-72323

CVSS 9.8 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.7HIGH

01

In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device 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 refcount_inc_not_zero() (via a new helper in_dev_hold_safe()) 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.

02

Engine v0.6.0

Risk summary

A race condition in the IPv4 IGMP subsystem allows a use-after-free when an incoming IGMP query is processed during network device teardown. A local unprivileged user can trigger this via user namespaces, potentially leading to kernel code execution or a system crash. Network-adjacent attackers can also exploit this by timing IGMP queries with device teardown events.

Affectednet/ipv4/igmp.c (IPv4 IGMP)

Vulnerability analysis

A race condition between network device teardown and incoming IGMP query processing can cause a timer to be armed on a device that is already being destroyed. The device memory is freed while the timer is still pending, so when the timer expires it accesses freed memory. The fix changes the timer setup to only proceed when the device is still active, skipping the operation entirely for devices being destroyed. This can be triggered by a local unprivileged user through user namespaces by creating and destroying network namespaces while sending IGMP queries, or by an attacker on the same network segment sending IGMP queries timed with device teardown on the target host.

03

BranchIntroducedFixed inPatch commit
5.102.6.125.10.2697265c747eec4
5.152.6.125.15.220d107b4c4f827
6.12.6.126.1.18774b301f7f197
6.122.6.126.12.97165258303357
6.182.6.126.18.4075e984fe0cb9
6.62.6.126.6.14540a1e998cb26
7.12.6.127.1.58d4394ffa405
mainline2.6.127.27b19c0f81ed1
cip/5.102.6.125.10.271-cip787265c747eec4
cip/5.10-rt2.6.125.10.272-cip79-rt357265c747eec4
cip/6.12.6.126.1.187-cip6074b301f7f197
cip/6.1-rt2.6.126.1.189-cip61-rt3274b301f7f197
cip/6.122.6.126.12.101-cip29165258303357

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.101-cip29
cip/6.1Fixed in 6.1.187-cip60
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Fixed in 5.10.271-cip78
cip/5.10-rtFixed in 5.10.272-cip79-rt35
cip/4.19Affected — no CIP fix yet (latest 4.19.325-cip136)
cip/4.19-rtAffected — no CIP fix yet (latest 4.19.325-cip136-rt50)
cip/4.4Affected — no CIP fix yet (latest 4.4.302-cip115)
cip/4.4-rtAffected — no CIP fix yet (latest 4.4.302-cip115-rt63)