CVE-2026-72323

CRITICALPre-NVD 9.89.8
EchelonGraph scoreHIGH confidence

Score 9.8 from GitHub Security Advisory (severity: CRITICAL) published 2026-08-15. a secondary CVSS source baseline 9.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
9.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 1%CVSS: 9.8Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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.

CVSS v3
9.8
EG Score
9.8(high)
EG Risk
49(Track)
EG Risk 49/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity98% × 45%
Exploitation1% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
1%
EPSS %ILE
48%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (5)

Auto-updated Aug 17, 2026
No patch confirmed yet.
generic

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/8d4394ffa40508e0de72f464af351f6ca6a6cdc3
generic

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/7b19c0f81ed1fdaec6bc522569be367199a9edf3
generic

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/75e984fe0cb9e7fbde0c8ee838c61ce8573d3ea3
generic

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/40a1e998cb266ed4cb529a0bb4fee2b0ba732702
generic

ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/165258303357e54b75fc19b341ae2a2b7c9e3910

Vendor Advisories for CVE-2026-72323(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 48× in last 7d / 48× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-21 01:46 UTCEG score recompute
  2. 2026-08-21 01:45 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 21:50 UTCGHSA enrichment
  5. 2026-08-20 17:56 UTCGHSA enrichment
  6. 2026-08-20 14:03 UTCGHSA enrichment
  7. 2026-08-20 10:08 UTCGHSA enrichment
  8. 2026-08-20 06:15 UTCGHSA enrichment
  9. 2026-08-20 02:18 UTCGHSA enrichment
  10. 2026-08-19 22:24 UTCGHSA enrichment
  11. 2026-08-19 18:29 UTCEG score recompute
  12. 2026-08-19 18:29 UTCGHSA enrichment
  13. 2026-08-19 17:04 UTCEPSS rescore
  14. 2026-08-19 14:34 UTCGHSA enrichment
  15. 2026-08-19 10:40 UTCGHSA enrichment
  16. 2026-08-19 06:44 UTCGHSA enrichment
  17. 2026-08-19 02:45 UTCGHSA enrichment
  18. 2026-08-18 22:47 UTCGHSA enrichment
  19. 2026-08-18 18:52 UTCGHSA enrichment
  20. 2026-08-18 14:58 UTCEG score recompute
  21. 2026-08-18 14:58 UTCGHSA enrichment
  22. 2026-08-18 13:49 UTCEPSS rescore
  23. 2026-08-18 13:49 UTCEPSS rescore
  24. 2026-08-18 10:39 UTCGHSA enrichment
  25. 2026-08-18 06:44 UTCGHSA enrichment
Show 23 more
  1. 2026-08-18 02:47 UTCGHSA enrichment
  2. 2026-08-17 22:53 UTCGHSA enrichment
  3. 2026-08-17 18:59 UTCGHSA enrichment
  4. 2026-08-17 14:17 UTCEG score recompute
  5. 2026-08-17 14:17 UTCGHSA enrichment
  6. 2026-08-17 13:47 UTCEPSS rescore
  7. 2026-08-17 10:23 UTCEG score recompute
  8. 2026-08-17 10:23 UTCGHSA enrichment
  9. 2026-08-17 06:30 UTCEG score recompute
  10. 2026-08-17 06:30 UTCGHSA enrichment
  11. 2026-08-17 05:59 UTCEG score recompute 9.80
  12. 2026-08-17 05:59 UTCGHSA enrichment
  13. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 9.8 · severity → CRITICAL
  14. 2026-08-17 05:30 UTCEG score recompute
  15. 2026-08-17 05:30 UTCGHSA enrichment
  16. 2026-08-17 05:24 UTCMITRE cvelistV5
  17. 2026-08-16 14:56 UTCEPSS rescore
  18. 2026-08-16 14:56 UTCEPSS rescore
  19. 2026-08-16 02:15 UTCEPSS rescore
  20. 2026-08-15 06:37 UTCGHSA enrichment
  21. 2026-08-15 06:23 UTCNVD update
  22. 2026-08-15 06:07 UTCEG score recompute
  23. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72323?
CVE-2026-72323 is a critical vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmpgqstart_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…
When was CVE-2026-72323 disclosed?
CVE-2026-72323 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-72323 actively exploited?
CVE-2026-72323 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 1% probability of exploitation in the next 30 days, which ranks it in the top 51.8% of all scored CVEs.
What is the CVSS score of CVE-2026-72323?
CVE-2026-72323 has a CVSS v3 base score of 9.8 (NVD).
How do I remediate CVE-2026-72323?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72323, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-72323

Explore →

Is Your Infrastructure Affected by CVE-2026-72323?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.