CVE-2026-90143 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net: kcm: Hold RCU read lock while running BPF parser
kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program.
Hold the RCU read lock while running the program.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's Kernel Connection Multiplexor (KCM) subsystem facilitates efficient data transfer between user-space applications and socket buffers by allowing multiple connections to share a single TCP connection. A critical flaw was identified in the kcm_parse_func_strparser function, which is responsible for invoking BPF programs to parse incoming network traffic. The core issue lies in the execution context of these BPF programs. Specifically, when bpf_prog_run_pin_on_cpu() is called within this parsing routine, it successfully pins the execution to a specific CPU to prevent migration and ensure performance consistency. However, this function does not automatically establish an RCU (Read-Copy-Update) read-side critical section. This omission creates a significant gap in synchronization primitives required for safe access to shared kernel data structures that are protected by RCU mechanisms.
The absence of the RCU read lock during BPF program execution leads to potential race conditions and instability within the kernel memory management subsystem. When the BPF parser performs operations on BPF maps or accesses other RCU-protected resources, it does so without holding the necessary reference count locks. This violation triggers a WARN_ON_ONCE(!bpf_rcu_lock_held()) condition in the kernel codebase. While this warning is designed to alert developers and system administrators of improper locking usage, its occurrence indicates that the BPF program is operating outside safe boundaries. In severe cases, or under specific timing conditions involving concurrent updates to RCU-protected data structures by other CPU cores, this lack of synchronization can lead to use-after-free vulnerabilities, kernel panics, or unpredictable behavior due to accessing memory that may have been freed or reallocated by another thread holding the corresponding write lock.
From a security and standards perspective, this vulnerability is classified under CWE-667, which denotes improper locking, specifically related to missing synchronization primitives for concurrent access. The attack vector aligns with ATT&CK technique T1059, Command and Scripting Interpreter, as BPF programs are often used in complex networking stacks where malicious or buggy eBPF code could exploit such race conditions if the kernel does not strictly enforce locking rules. Although the immediate manifestation is a warning log rather than an arbitrary code execution flaw, the underlying issue represents a fundamental breach of concurrency safety principles. It highlights the critical importance of adhering to RCU semantics in high-performance networking paths where lock contention must be minimized but correctness cannot be compromised.
To mitigate this vulnerability, it is essential that the kernel developers ensure all BPF programs executed within network parsing contexts properly acquire and release RCU read locks before accessing any shared data structures protected by RCU. The fix involves wrapping the bpf_prog_run_pin_on_cpu() call with rcu_read_lock() and rcu_read_unlock() primitives respectively. This ensures that during the execution of the BPF parser, the kernel maintains a consistent view of memory for other concurrent readers while preventing premature freeing of data structures. System administrators should apply the latest available kernel patches to their systems to resolve this synchronization issue. Regular auditing of eBPF programs and strict adherence to RCU usage guidelines in network subsystem development are recommended practices to prevent similar concurrency-related vulnerabilities in future iterations of the Linux networking stack.