CVE-2026-64352

UNRATEDCVSS · not yet scoredTrending — 3 sources updated this week
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS v2: Exploit: 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:

bpf: Allow LPM map access from sleepable BPF programs

trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace().

trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there.

A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels:

============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64

This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common.

For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention.

For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.

CVSS v3
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
EG Risk
EPSS PROB
0%
EPSS %ILE
7%
KEV
Not listed

Published

July 25, 2026

Last Modified

August 17, 2026

Vendor Advisories for CVE-2026-64352(2)

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

Affected Packages

(5 across 4 ecosystems)
Debian:12(2)
PackageVulnerable rangeFixed inDependents
linux6.1.106-1 ... 6.1.99-1 (55 versions)6.1.180-1
linux-6.126.12.100-1~deb12u1
Debian:11(1)
PackageVulnerable rangeFixed inDependents
linux-6.16.1.106-3~deb11u1 ... 6.1.177-1~deb11u1 (22 versions)6.1.180-1~deb11u1
Debian:13(1)
PackageVulnerable rangeFixed inDependents
linux6.12.38-1 ... 6.12.96-1 (31 versions)6.12.100-1
Debian:14(1)
PackageVulnerable rangeFixed inDependents
linux6.12.100-1 ... 7.1~rc7-1~exp1 (156 versions)7.1.4-1

Data Freshness Timeline

(refreshed 10× in last 7d / 43× 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-30 01:22 UTCEPSS rescore
  2. 2026-08-30 00:10 UTCVendor advisory
  3. 2026-08-30 00:10 UTCGHSA enrichment
  4. 2026-08-28 21:42 UTCEPSS rescore
  5. 2026-08-26 14:49 UTCVendor advisory
  6. 2026-08-26 14:49 UTCGHSA enrichment
  7. 2026-08-26 14:47 UTCEPSS rescore
  8. 2026-08-25 13:49 UTCEPSS rescore
  9. 2026-08-23 11:37 UTCVendor advisory
  10. 2026-08-23 11:37 UTCGHSA enrichment
  11. 2026-08-23 00:19 UTCEPSS rescore
  12. 2026-08-21 23:49 UTCEPSS rescore
  13. 2026-08-20 22:55 UTCEPSS rescore
  14. 2026-08-20 08:28 UTCVendor advisory
  15. 2026-08-20 08:28 UTCGHSA enrichment
  16. 2026-08-19 17:04 UTCEPSS rescore
  17. 2026-08-17 13:47 UTCEPSS rescore
  18. 2026-08-17 05:25 UTCNVD update
  19. 2026-08-17 05:19 UTCVendor advisory
  20. 2026-08-17 05:19 UTCGHSA enrichment
  21. 2026-08-17 05:05 UTCMITRE cvelistV5
  22. 2026-08-16 14:56 UTCEPSS rescore
  23. 2026-08-15 01:30 UTCEPSS rescore
  24. 2026-08-14 18:17 UTCVendor advisory
  25. 2026-08-14 18:17 UTCGHSA enrichment
Show 34 more
  1. 2026-08-12 13:51 UTCEPSS rescore
  2. 2026-08-11 15:08 UTCVendor advisory
  3. 2026-08-11 15:08 UTCGHSA enrichment
  4. 2026-08-11 00:00 UTCEPSS rescore
  5. 2026-08-10 18:56 UTCGHSA enrichment
  6. 2026-08-09 13:47 UTCEPSS rescore
  7. 2026-08-08 16:37 UTCEPSS rescore
  8. 2026-08-07 15:47 UTCGHSA enrichment
  9. 2026-08-06 13:47 UTCEPSS rescore
  10. 2026-08-05 19:17 UTCEPSS rescore
  11. 2026-08-05 19:17 UTCEPSS rescore
  12. 2026-08-04 15:10 UTCEPSS rescore
  13. 2026-08-04 12:38 UTCGHSA enrichment
  14. 2026-08-03 10:36 UTCEPSS rescore
  15. 2026-08-02 02:27 UTCEPSS rescore
  16. 2026-08-01 09:07 UTCEG score recompute
  17. 2026-08-01 09:07 UTCGHSA enrichment
  18. 2026-08-01 04:16 UTCEPSS rescore
  19. 2026-07-30 16:28 UTCEPSS rescore
  20. 2026-07-30 01:30 UTCEPSS rescore
  21. 2026-07-30 01:30 UTCEPSS rescore
  22. 2026-07-29 05:58 UTCEG score recompute
  23. 2026-07-29 05:58 UTCGHSA enrichment
  24. 2026-07-28 15:37 UTCEPSS rescore
  25. 2026-07-27 14:14 UTCEPSS rescore
  26. 2026-07-26 14:54 UTCEPSS rescore
  27. 2026-07-26 14:54 UTCEPSS rescore
  28. 2026-07-26 02:50 UTCEG score recompute
  29. 2026-07-26 02:49 UTCGHSA enrichment
  30. 2026-07-25 14:18 UTCEPSS rescore
  31. 2026-07-25 14:18 UTCEPSS rescore
  32. 2026-07-25 10:39 UTCNVD update
  33. 2026-07-25 09:37 UTCEG score recompute
  34. 2026-07-25 09:21 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-64352?
CVE-2026-64352 is a publicly disclosed vulnerability published on July 25, 2026. In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trielookupelem() annotates its rcudereferencecheck() walks with only rcureadlockbhheld(). Because rcudereferencecheck(p, c) resolves to "c || rcureadlock_held()", this passes…
When was CVE-2026-64352 disclosed?
CVE-2026-64352 was first published in the National Vulnerability Database on July 25, 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-64352 actively exploited?
CVE-2026-64352 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 93.2% of all scored CVEs.
How do I remediate CVE-2026-64352?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-64352, 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

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-64352

Explore →

Is Your Infrastructure Affected by CVE-2026-64352?

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