GHSA-P2WC-GRC5-CWHM
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-03 18:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-64352"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Allow LPM map access from sleepable BPF programs\n\ntrie_lookup_elem() annotates its rcu_dereference_check() walks with\nonly rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c)\nresolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and\nclassic RCU readers but fails for sleepable BPF programs, which enter\nvia __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace().\n\ntrie_update_elem() and trie_delete_elem() have the same problem in a\ndifferent form: they walk the trie with plain rcu_dereference(), which\nasserts rcu_read_lock_held() unconditionally. Both are reachable from\nsleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem\nhelpers, and from the syscall path under classic rcu_read_lock(). In\nthe writer paths the trie is actually protected by trie-\u003elock (an\nrqspinlock taken across the walk); we never relied on the RCU read-side\nlock to keep nodes alive there.\n\nA sleepable LSM hook that ends up touching an LPM trie therefore\ntriggers lockdep on debug kernels:\n\n =============================\n WARNING: suspicious RCU usage\n 7.1.0-... Tainted: G E\n -----------------------------\n kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage!\n 1 lock held by net_tests/540:\n #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},\n at: __bpf_prog_enter_sleepable+0x26/0x280\n Call Trace:\n dump_stack_lvl\n lockdep_rcu_suspicious\n trie_lookup_elem\n bpf_prog_..._enforce_security_socket_connect\n bpf_trampoline_...\n security_socket_connect\n __sys_connect\n do_syscall_64\n\nThis is lockdep-only -- no UAF, since Tasks Trace RCU does serialize\nagainst the trie\u0027s reclaim path -- but it spams the console once per\ndistinct callsite on every debug kernel running a sleepable BPF LSM\nthat touches an LPM trie, which is increasingly common.\n\nFor the lookup path, switch the rcu_dereference_check() annotation\nfrom rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all\nthree contexts (classic, BH, Tasks Trace). Other map types already\nfollow this convention.\n\nFor trie_update_elem() and trie_delete_elem(), annotate the walks as\nrcu_dereference_protected(*p, 1) -- matching trie_free() in the same\nfile -- since trie-\u003elock is held across the walk. rqspinlock has no\nlockdep_map, so the predicate degenerates to \u00271\u0027 rather than\nlockdep_is_held(\u0026trie-\u003elock); the protection is real but not\nmachine-verifiable. trie_get_next_key() also uses bare\nrcu_dereference() but is reachable only from the BPF syscall, which\nholds classic rcu_read_lock() before dispatching, so it is left\nuntouched.",
"id": "GHSA-p2wc-grc5-cwhm",
"modified": "2026-09-03T18:31:17Z",
"published": "2026-07-25T12:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64352"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f884d371fafea137afea504d49ee4a7c8d7985b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/304ca50582f0c047370f85e13caec456f78c9fcc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57454944737f3ad9a8703aecbbb79713b513a94b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bfdf4b81b0e56d47bc6c46c34a46638be716695"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd6ad9a6b30498d845413e863fb95c6fab3babe3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec662a8b2cde01e76b37ccd4b992d0342299e69c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0967d4f1ba4323a3cb7dc8fdba74dd3a8caaf04"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.