CVE-2026-92485 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARNING in bpf_tracing_link_release
The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier.
1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn.
[ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98
... [ 3.428793] bpf_link_free+0x58/0x130
[ 3.429293] bpf_link_release+0x23/0x30
Fix the warning by updating 'tr->flags' with '|=' and lock.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a critical flaw within its Berkeley Packet Filter (BPF) tracing subsystem, specifically involving the management of trampoline flags during fexit program attachment and detachment operations. This vulnerability arises from improper state handling in the verifier when dealing with tail-call reachable programs. The core issue stems from the use of an assignment operator rather than a bitwise OR operation when updating the trampoline's flag field. Specifically, the code blindly sets 'tr->flags' to 'BPF_TRAMP_F_TAIL_CALL_CTX', which overwrites any existing flags that were previously set for that specific trampoline instance. This lack of atomic state accumulation leads to data corruption within the kernel's internal representation of BPF tracing links, ultimately causing a warning condition in bpf_tracing_link_release and potentially destabilizing the system if not handled correctly by subsequent operations.
The operational impact manifests through a sequence of events involving multiple fexit programs attached to the same tail-call reachable target program. Initially, when an fexit is attached to such a program, the trampoline flags are set to include both 'BPF_TRAMP_F_CALL_ORIG' and 'BPF_TRAMP_F_TAIL_CALL_CTX'. This configuration ensures that the trampoline correctly patches the target program's instruction pointer by replacing a no-operation instruction with a jump instruction. However, when a second fexit is loaded targeting the same tail-call reachable program, the verifier incorrectly overwrites the existing flags, retaining only 'BPF_TRAMP_F_TAIL_CALL_CTX' and discarding the crucial 'BPF_TRAMP_F_CALL_ORIG' flag. This loss of state information means that the system no longer recognizes the need to preserve or restore the original call context for subsequent detachments.
The consequence becomes apparent when the first fexit link is closed. Because the trampoline flags now lack the 'BPF_TRAMP_F_CALL_ORIG' indicator, the kernel fails to properly restore the target program's instruction by replacing the jump with a call instruction as intended during cleanup. This failure results in an inconsistent execution state where the patched code may not revert correctly, leading to undefined behavior or crashes. The immediate symptom is a kernel warning generated at bpf_tracing_link_release, indicating that the link free operation encountered an unexpected condition due to this corrupted flag state. While often manifested as a warning, such memory and logic corruption can escalate into more severe stability issues depending on how the kernel handles subsequent accesses to these malformed structures.
This vulnerability is classified under CWE-672, which refers to the use of operations with unintended side effects or incorrect application of operators that lead to state inconsistency. In terms of attack vectors, this flaw aligns with ATT&CK technique T1059, specifically command and scripting interpreter abuse via kernel modules or eBPF programs, as an attacker could potentially exploit the improper flag handling to manipulate execution flow within the kernel space. The root cause is a classic logic error where bitwise operations are required but simple assignment is used, failing to preserve existing state bits that are critical for correct resource management and code patching integrity.
To mitigate this vulnerability, developers must update the trampoline flag modification logic to use bitwise OR assignment instead of direct assignment. This ensures that new flags are added without overwriting existing ones, thereby preserving the 'BPF_TRAMP_F_CALL_ORIG' status when multiple fexit programs target the same tail-call reachable program. Additionally, proper locking mechanisms should be employed during these updates to prevent race conditions where concurrent modifications could still lead to inconsistent states even with bitwise operations. Applying this patch ensures that trampoline cleanup routines can correctly identify all active attachments and restore the original code instructions accurately, maintaining kernel stability and security integrity for BPF tracing workloads.