CVE-2026-72404

HIGHPre-NVD 7.87.8
EchelonGraph scoreHIGH confidence

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

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
7.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 7.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:

tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy()

TIPC UDP media bearer teardown calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish:

static void cleanup_bearer(struct work_struct *work) { ... list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { dst_cache_destroy(&rcast->dst_cache); list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache); udp_tunnel_sock_release(ub->sk); synchronize_net(); ... }

This is highly buggy because dst_cache_destroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization.

If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU protection, it can call dst_cache_get() concurrently, leading to:

  • Use-After-Free on the per-CPU cache pointer itself (crash).
  • "rcuref - imbalanced put()" warning if it attempts to release a
dst that was concurrently released by dst_cache_destroy().

Furthermore, calling kfree(ub) immediately after synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs.

To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished:

  • Defer rcast entry destruction (both dst_cache_destroy() and kfree())
to an RCU callback using call_rcu_hurry(). Using call_rcu_hurry() ensures the dst entries are released quickly.
  • Release the bearer socket using udp_tunnel_sock_release() (stops
new receive readers).
  • Call synchronize_net() to wait for all outstanding RCU readers
(both transmit and receive) to finish.
  • Now that it is safe, call dst_cache_destroy() on the main bearer
cache, and free ub.

Note: 3) and 4) can be changed later in net-next to also use call_rcu_hurry() and get rid of the synchronize_net() latency.

CVSS v3
7.8
EG Score
7.8(high)
EG Risk
40(Track)
EG Risk 40/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
Severity78% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
5%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (2)

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

tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/7116764ca53ff529335d7ab7c364a69f094b23a5
generic

tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/1c8393eefa3cadf4ca0b61119ad1321aa32d3c8c

Vendor Advisories for CVE-2026-72404(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 30× in last 7d / 30× 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-20 22:56 UTCEPSS rescore
  2. 2026-08-20 20:38 UTCGHSA enrichment
  3. 2026-08-20 08:21 UTCGHSA enrichment
  4. 2026-08-19 20:05 UTCEG score recompute
  5. 2026-08-19 20:05 UTCGHSA enrichment
  6. 2026-08-19 17:04 UTCEPSS rescore
  7. 2026-08-19 07:49 UTCGHSA enrichment
  8. 2026-08-18 19:32 UTCEG score recompute
  9. 2026-08-18 19:32 UTCGHSA enrichment
  10. 2026-08-18 13:49 UTCEPSS rescore
  11. 2026-08-18 13:49 UTCEPSS rescore
  12. 2026-08-18 07:15 UTCGHSA enrichment
  13. 2026-08-17 18:59 UTCEG score recompute
  14. 2026-08-17 18:59 UTCGHSA enrichment
  15. 2026-08-17 13:47 UTCEPSS rescore
  16. 2026-08-17 06:29 UTCEG score recompute
  17. 2026-08-17 06:29 UTCGHSA enrichment
  18. 2026-08-17 05:57 UTCEG score recompute 7.80
  19. 2026-08-17 05:57 UTCGHSA enrichment
  20. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 7.8 · severity → HIGH
  21. 2026-08-17 05:29 UTCEG score recompute
  22. 2026-08-17 05:29 UTCGHSA enrichment
  23. 2026-08-17 05:25 UTCMITRE cvelistV5
  24. 2026-08-16 14:56 UTCEPSS rescore
  25. 2026-08-16 14:56 UTCEPSS rescore
Show 5 more
  1. 2026-08-16 02:15 UTCEPSS rescore
  2. 2026-08-15 06:34 UTCGHSA enrichment
  3. 2026-08-15 06:23 UTCNVD update
  4. 2026-08-15 06:05 UTCEG score recompute
  5. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72404?
CVE-2026-72404 is a high vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in cleanupbearer() due to premature dstcache_destroy() TIPC UDP media bearer teardown calls dstcachedestroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters)…
When was CVE-2026-72404 disclosed?
CVE-2026-72404 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-72404 actively exploited?
CVE-2026-72404 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 94.9% of all scored CVEs.
What is the CVSS score of CVE-2026-72404?
CVE-2026-72404 has a CVSS v3 base score of 7.8 (NVD).
How do I remediate CVE-2026-72404?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72404, 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-72404

Explore →

Is Your Infrastructure Affected by CVE-2026-72404?

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