CVE-2026-64352

What it actually does

This Linux kernel flaw is an eBPF LPM trie RCU-locking annotation issue affecting sleepable BPF program contexts. When a sleepable BPF LSM program accesses an LPM trie map through lookup, update, or delete helpers, debug kernels with lockdep enabled can report suspicious RCU usage because the code checks for classic or bottom-half RCU read locks rather than the Tasks Trace RCU context used by sleepable BPF programs. The upstream description indicates this is lockdep-only: it is not believed to create a use-after-free or direct memory corruption condition. The practical technical impact is repeated kernel warning generation, console/log noise, and potential operational degradation on debug or lockdep-enabled kernels running sleepable BPF programs that use LPM trie maps.

Why it matters to the business

The main business risk is instability or operational disruption in Linux environments that run debug or lockdep-enabled kernels with eBPF-based security, observability, or policy enforcement components. Repeated kernel warnings can flood logs, obscure real incidents, increase storage and monitoring costs, and create alert fatigue. Because exploitation requires a specific BPF configuration and the issue is not known to provide code execution, privilege escalation, or data theft, the broad business risk is low; this is also reflected by the low EPSS score and lack of CISA KEV listing.

How an attack unfolds

An attacker or misconfigured local component would need the ability to load or influence sleepable BPF programs, typically requiring elevated privileges or access to a privileged BPF deployment path. The attacker creates or uses a sleepable BPF LSM hook that interacts with an LPM trie BPF map, then triggers the hooked kernel operation, such as a socket connect path. When the BPF program calls helpers such as bpf_map_lookup_elem, bpf_map_update_elem, or bpf_map_delete_elem against the LPM trie, the kernel traverses the trie under an RCU context that lockdep does not recognize as acceptable in the vulnerable code path. On debug kernels, this causes repeated "suspicious RCU usage" warnings associated with kernel/bpf/lpm_trie.c. The likely result is console and log flooding rather than compromise of confidentiality or integrity.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the BPF LPM trie RCU annotation issue. No exact fixed package versions were provided in the input, so use the fixed kernel release supplied by the relevant Linux distribution or kernel vendor once available. Where immediate patching is not possible, reduce exposure by avoiding sleepable BPF LSM programs that access LPM trie maps on debug or lockdep-enabled kernels, disabling nonessential privileged BPF workloads, restricting BPF program loading to trusted administrators, and ensuring unprivileged BPF is disabled where supported. Production systems should generally avoid running debug/lockdep kernels unless explicitly required for diagnostics.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix for BPF LPM trie access from sleepable BPF programs. Validate by checking the installed kernel changelog or vendor advisory for a fix referencing BPF LPM trie, sleepable BPF programs, bpf_rcu_lock_held(), or lpm_trie.c RCU annotations. On test systems, reproduce the previously affected scenario using a sleepable BPF LSM program that accesses an LPM trie map and confirm that kernel logs no longer emit suspicious RCU usage warnings from kernel/bpf/lpm_trie.c. Also verify that unprivileged BPF remains disabled if not required and that only trusted roles can load BPF programs.

Typical attack path

1. Gain local privileged capability to load or modify eBPF programs, or compromise a privileged component that manages BPF programs.
2. Create or influence a sleepable BPF LSM program that uses an LPM trie map.
3. Attach the sleepable BPF program to an LSM hook reachable through normal system activity, such as socket connection handling.
4. Trigger the hooked operation repeatedly so the BPF program accesses the LPM trie through lookup, update, or delete helpers.
5. Cause lockdep-enabled kernels to emit repeated suspicious RCU usage warnings, creating log noise or operational disruption.

How to detect it

To determine whether this condition has already occurred, review kernel logs, system journals, console captures, crash/diagnostic bundles, and SIEM-ingested syslog for lockdep warnings referencing suspicious RCU usage in the BPF LPM trie implementation. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, distribution-specific kernel logs, and centralized logging pipelines. Focus on messages containing "WARNING: suspicious RCU usage", "kernel/bpf/lpm_trie.c", "trie_lookup_elem", "trie_update_elem", or "trie_delete_elem" near BPF LSM hook activity. Correlate events with BPF program load activity, changes to BPF-based security or observability agents, and repeated system calls that exercise LSM hooks such as socket connect operations. Because the issue is described as lockdep-only, these logs are indicators of triggering/exposure rather than proof of privilege escalation or memory corruption.

• WARNING: suspicious RCU usage
• kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage
• kernel/bpf/lpm_trie.c
• trie_lookup_elem
• trie_update_elem
• trie_delete_elem
• __bpf_prog_enter_sleepable
• rcu_tasks_trace_srcu_struct
• bpf_map_update_elem
• bpf_map_delete_elem
• bpf_prog_
• enforce_security_socket_connect
• security_socket_connect
• lockdep_rcu_suspicious

What your security team should do

• Prioritize patching debug, staging, CI, and observability/security appliance kernels that run lockdep-enabled builds and use eBPF LSM programs.
• Inventory systems using sleepable BPF programs and LPM trie maps, especially BPF-based security enforcement, networking policy, or observability agents.
• Restrict BPF program loading to trusted administrative users and service accounts; disable unprivileged BPF where supported.
• Monitor kernel logs for suspicious RCU usage warnings involving kernel/bpf/lpm_trie.c, trie_lookup_elem, trie_update_elem, or trie_delete_elem.
• Treat repeated warnings as an operational reliability issue and investigate the responsible BPF program or agent, but do not assume successful code execution solely from these messages.
• Track distribution kernel advisories for this issue because exact fixed versions were not provided.