CVE-2026-72323

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()

State
Published
Severity
9.8 Critical
Published
Aug 15, 2026
Updated
Oct 16, 2026
Reserved
Aug 9, 2026

Read the record on cve.org

Description

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.

Scores

CVSSScoreVectorSource
3.19.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 7265c747eec415ca3109a6a14a419f7ae433b780Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before d107b4c4f8274763b7ea5ab05d45cef78e4b81baAffected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 74b301f7f197517016befb5f5dfab01f7bc64be5Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 40a1e998cb266ed4cb529a0bb4fee2b0ba732702Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 165258303357e54b75fc19b341ae2a2b7c9e3910Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 75e984fe0cb9e7fbde0c8ee838c61ce8573d3ea3Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 8d4394ffa40508e0de72f464af351f6ca6a6cdc3Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 7b19c0f81ed1fdaec6bc522569be367199a9edf3Affected
LinuxLinux
  • 2.6.12Affected
  • before 2.6.12Not affected
  • 5.10.269 through 5.10.*Not affected
  • 5.15.220 through 5.15.*Not affected
  • 6.1.187 through 6.1.*Not affected
  • 6.6.145 through 6.6.*Not affected
  • 6.12.97 through 6.12.*Not affected
  • 6.18.40 through 6.18.*Not affected
  • 7.1.5 through 7.1.*Not affected
  • 7.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.