CVE-2026-92485: bpf: Fix WARNING in bpf_tracing_link_release
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARNING in bpftracinglinkrelease
The trampoline could be corrupted by the blindly 'tr->flags = BPFTRAMPFTAILCALLCTX' in verifier.
1. A fexit attached to a tailcallreachable prog. 'tr->flags' became 'BPFTRAMPFCALLORIG | BPFTRAMPFTAILCALLCTX'. 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 tailcallreachable prog target. 'tr->flags' became 'BPFTRAMPFTAILCALLCTX'. 3. Close the first fexit link. Due to no BPFTRAMPFCALLORIG 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 bpftracinglinkrelease+0x53/0x60, CPU#1: testprogs/98 ... [ 3.428793] bpflinkfree+0x58/0x130 [ 3.429293] bpflinkrelease+0x23/0x30
Fix the warning by updating 'tr->flags' with '|=' and lock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1 - Compensating control
In the Linux kernel BPF verifier, update tr->flags with a locked '|=' operation instead of blindly assigning BPF_TRAMP_F_TAIL_CALL_CTX, preserving BPF_TRAMP_F_CALL_ORIG when present.
Event History
Frequently Asked Questions
What conditions are needed to trigger the warning?
The sequence requires an fexit program attached to a tail-call-reachable program, followed by loading another fexit program with the same target, then closing the first fexit link. This can leave trampoline flags inconsistent and prevent restoration of the target program's nop instruction.
How can I tell whether this has occurred?
The kernel emits a WARNING at bpf_tracing_link_release during release of a BPF tracing link. The reported stack includes bpf_link_free and bpf_link_release, and may identify a test_progs process.