CVE-2026-64352 Overview
CVE-2026-64352 affects the Linux kernel's Berkeley Packet Filter (BPF) subsystem, specifically the Longest Prefix Match (LPM) trie map implementation in kernel/bpf/lpm_trie.c. The trie_lookup_elem() function annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(), which fails validation for sleepable BPF programs that enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). The writer paths trie_update_elem() and trie_delete_elem() exhibit a similar problem using plain rcu_dereference() that unconditionally asserts rcu_read_lock_held(). On debug kernels running sleepable BPF Linux Security Module (LSM) hooks that touch an LPM trie, lockdep emits suspicious Read-Copy-Update (RCU) usage warnings.
Critical Impact
This is a lockdep-only annotation issue with no use-after-free risk, but it produces repeated console warnings on debug kernels running sleepable BPF LSM programs that access LPM tries.
Affected Products
- Linux kernel BPF subsystem (kernel/bpf/lpm_trie.c)
- Kernels supporting sleepable BPF programs and BPF LSM hooks
- Debug kernel builds with lockdep enabled
Discovery Timeline
- 2026-07-25 - CVE-2026-64352 published to the National Vulnerability Database (NVD)
- 2026-07-25 - Last updated in NVD database
Technical Details for CVE-2026-64352
Vulnerability Analysis
The issue centers on inconsistent RCU annotations in the LPM trie map implementation. The macro rcu_dereference_check(p, c) resolves to c || rcu_read_lock_held(), which passes for eXpress Data Path (XDP) and New API (NAPI) contexts and classic RCU readers, but fails for sleepable BPF programs. Sleepable BPF programs enter through __bpf_prog_enter_sleepable() and hold only Tasks Trace SRCU (rcu_tasks_trace_srcu_struct), not the classic RCU read-side lock.
Both trie_update_elem() and trie_delete_elem() are reachable from sleepable BPF programs via the bpf_map_update_elem and bpf_map_delete_elem helpers, as well as from the syscall path under classic rcu_read_lock(). In the writer paths, the trie is protected by trie->lock (an rqspinlock held across the walk), so RCU read-side protection was never required for node liveness there.
Root Cause
The root cause is a mismatch between the RCU protection contexts declared by the code and the actual contexts from which the functions are invoked. The lookup path declares only Bottom Half (BH) RCU protection, while sleepable callers hold Tasks Trace RCU. The writer paths use bare rcu_dereference() that ignores the actual trie->lock protection.
Attack Vector
No attack vector exists. This vulnerability produces lockdep warnings only on debug kernels and does not correspond to a memory-safety flaw. Tasks Trace RCU serializes against the trie's reclaim path, so no use-after-free (UAF) condition is present. The observable symptom is repeated WARNING: suspicious RCU usage messages in kernel logs when a sleepable BPF LSM hook such as a security_socket_connect enforcement program traverses an LPM trie.
The vulnerability is described in prose only; refer to the upstream kernel patch commits listed in the references for the exact annotation changes applied to trie_lookup_elem(), trie_update_elem(), and trie_delete_elem().
Detection Methods for CVE-2026-64352
Indicators of Compromise
- Kernel log entries containing WARNING: suspicious RCU usage referencing kernel/bpf/lpm_trie.c:249
- Stack traces including trie_lookup_elem, bpf_trampoline_, __bpf_prog_enter_sleepable, and lockdep_rcu_suspicious
- Repeated warnings emitted once per distinct callsite on debug kernels running sleepable BPF LSM programs
Detection Strategies
- Review dmesg and journal output on debug kernels for lockdep RCU warnings tied to lpm_trie.c
- Correlate warning callsites with loaded BPF LSM programs that use LPM trie maps via bpftool prog show and bpftool map show
- Audit sleepable BPF program attachments to security hooks such as security_socket_connect
Monitoring Recommendations
- Aggregate kernel warning messages centrally and alert on lockdep_rcu_suspicious events
- Track kernel version deployment status against the upstream stable branches carrying the fix commits
- Monitor sleepable BPF program load events and their target hook points for change tracking
How to Mitigate CVE-2026-64352
Immediate Actions Required
- Apply the upstream stable kernel patches referenced in the CVE record to affected kernel versions
- On production kernels, prioritize updates to Long Term Support (LTS) branches that receive the backported fix
- Validate that sleepable BPF LSM workloads continue to function after the annotation changes
Patch Information
The fix switches the lookup path's rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts classic RCU, BH RCU, and Tasks Trace RCU contexts. The writer paths trie_update_elem() and trie_delete_elem() are annotated as rcu_dereference_protected(*p, 1) to match trie_free() in the same file, reflecting that trie->lock protects the walk. trie_get_next_key() is left unchanged because it is reachable only from the BPF syscall under classic rcu_read_lock(). See the upstream commits: Kernel Patch Commit 2f884d3, Kernel Patch Commit 304ca50, Kernel Patch Commit 5745494, Kernel Patch Commit 9bfdf4b, Kernel Patch Commit bd6ad9a, Kernel Patch Commit ec662a8, and Kernel Patch Commit f0967d4.
Workarounds
- Disable lockdep (CONFIG_LOCKDEP) on production kernels to suppress the warnings, at the cost of losing broader lock-debugging coverage
- Avoid attaching sleepable BPF LSM programs that touch LPM trie maps until the patch is applied
- Rate-limit or filter kernel log ingestion for the specific lpm_trie.c warning signature to prevent log flooding
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
