In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Refactor jump offset calculation in tail call
The old macro-based jmp_offset calculation derives the jump distance
from a stale prior-pass code stride, which can lead to wrong branch
offsets and soft lockups under extra JIT passes.
Fix this by calculating the offset directly on the absolute target:
"ctx->offset[insn + 1] - ctx->idx".
To avoid a false 16-bit range check abort during size estimation, add
a "ctx->image == NULL" guard to inject a safe dummy offset.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The bug is in the LoongArch eBPF JIT emit_bpf_tail_call() and is reached only by loading a program that uses bpf_tail_call via bpf(BPF_PROG_LOAD) on the local host. Kernel CNA guidance classifies BPF as a local attack vector.
AC:L - The attacker fully controls the BPF bytecode, including bpf2bpf subprograms that force the extra JIT pass where the stale prior-pass stride is used. Wrong jmp_offset encodings are deterministic for a given program (the in-tree tailcall_bpf2bpf_1 case), with no race or layout outside attacker control.
PR:L - BPF_MAP_TYPE_PROG_ARRAY is an unprivileged map type, bpf_tail_call_proto is returned before the CAP_BPF gate, and SOCKET_FILTER programs load without CAP_BPF where unprivileged BPF is enabled. Otherwise only CAP_BPF or a delegated BPF token in a user namespace is required, not init-namespace root.
UI:N - The attacker loads the crafted program, attaches it to a socket they own or runs it with BPF_PROG_TEST_RUN, and triggers the miscompiled tail call themselves. No separate victim action is required.
S:U - The wrong branches execute inside the host kernel's own JIT image and corrupt in-kernel control flow. That is standard kernel privilege-escalation impact, not a VM, IOMMU, or hypervisor boundary crossing.
C:H - Miscomputed tail-call "goto out" branches can land inside the remaining sequence after the max_entries check, so an out-of-range index performs an OOB load of array->ptrs[] and treats the result as a function pointer, disclosing kernel memory. Mid-image jumps likewise execute attacker-shaped JIT loads at kernel privilege.
I:H - The same OOB ptrs[] load is followed by an indirect jump through prog->bpf_func, hijacking kernel control flow. Branches that skip the NULL or tail-call-count checks, or that land mid-instruction, likewise yield a kernel-mode write and control-flow primitive.
A:H - The fix and the prior incomplete tail-call offset patch document watchdog soft lockups from wrong, including backward, branches looping in kernel context. Any such hang, oops, or panic is Availability High.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is in the LoongArch eBPF JIT emit_bpf_tail_call() and is reached only by loading a program that uses bpf_tail_call via bpf(BPF_PROG_LOAD) on the local host. Kernel CNA guidance classifies BPF as a local attack vector.
AC:L - The attacker fully controls the BPF bytecode, including bpf2bpf subprograms that force the extra JIT pass where the stale prior-pass stride is used. Wrong jmp_offset encodings are deterministic for a given program (the in-tree tailcall_bpf2bpf_1 case), with no race or layout outside attacker control.
PR:L - BPF_MAP_TYPE_PROG_ARRAY is an unprivileged map type, bpf_tail_call_proto is returned before the CAP_BPF gate, and SOCKET_FILTER programs load without CAP_BPF where unprivileged BPF is enabled. Otherwise only CAP_BPF or a delegated BPF token in a user namespace is required, not init-namespace root.
UI:N - The attacker loads the crafted program, attaches it to a socket they own or runs it with BPF_PROG_TEST_RUN, and triggers the miscompiled tail call themselves. No separate victim action is required.
S:U - The wrong branches execute inside the host kernel's own JIT image and corrupt in-kernel control flow. That is standard kernel privilege-escalation impact, not a VM, IOMMU, or hypervisor boundary crossing.
C:H - Miscomputed tail-call "goto out" branches can land inside the remaining sequence after the max_entries check, so an out-of-range index performs an OOB load of array->ptrs[] and treats the result as a function pointer, disclosing kernel memory. Mid-image jumps likewise execute attacker-shaped JIT loads at kernel privilege.
I:H - The same OOB ptrs[] load is followed by an indirect jump through prog->bpf_func, hijacking kernel control flow. Branches that skip the NULL or tail-call-count checks, or that land mid-instruction, likewise yield a kernel-mode write and control-flow primitive.
A:H - The fix and the prior incomplete tail-call offset patch document watchdog soft lockups from wrong, including backward, branches looping in kernel context. Any such hang, oops, or panic is Availability High.
CVSS 3.1