Look up another CVE · open CVE-2025-22048 in the interactive tracker
CVE-2025-22048
LoongArch: BPF: Don't override subprog's return value
Published 2025-04-16 (18 months ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-22048 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.25-1 | Update the kernel and reboot. Fixed in 6.12.25-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.25-1 | Update the kernel and reboot. Fixed in 6.12.25-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.25-1 | Update the kernel and reboot. Fixed in 6.12.25-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/loongarch/net/bpf_jit.c
- What this is
- BPF JIT for LOONGARCHMAINTAINERS section matched on arch/loongarch/net/ · bpf@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_BPF_JIT /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormy
- trixie, forky, sidYnot built on s390x/s390x
- y
- built into the kernel image on every flavour - only a patch removes it
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_BPF_JIT
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-04-16 (18 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.21%, higher than 11.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6.64 | 6.6.87 | 7df2696256a0 |
| 6.12.2 | 6.12.23 | 223d565d8892 |
| 6.13 | 6.13.11 | 780628a780b6 |
| 6.13 | 6.14.2 | 996e90ab4466 |
| 6.13 | 6.15 | 60f3caff1492 |
| 6.1.120 | 0 | 0 |
| 6.11.11 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires loading a JITed eBPF program containing a bpf2bpf subprog call via the bpf() syscall on the local system. Per kernel scoring guidance, BPF is a Local attack vector.
- AC:LAttack complexity, low
- The miscompilation is deterministic — every bpf2bpf call site in a JITed program on LoongArch unconditionally clobbers R0 with the sign-extended low 32 bits, with no race, timing, or memory-layout precondition for the corruption itself. The attacker fully controls the program text, the returned pointer type, and the dereference offset.
- PR:LPrivileges required, low
- Loading a subprog-containing SOCKET_FILTER/CGROUP_SKB program needs no capability at all when kernel.unprivileged_bpf_disabled=0, a supported and widely-deployed setting (and the default when CONFIG_BPF_UNPRIV_DEFAULT_OFF=n, common on vendor/embedded LoongArch kernels). Otherwise only CAP_BPF is required, which is by design not root-equivalent and is exactly the low-privilege principal the verifier is supposed to contain.
- UI:NUser interaction, none
- The attacker loads the program and triggers it entirely on their own — e.g. attaching a socket filter to their own socket and sending a loopback packet. No victim action is involved.
- S:UScope, unchanged
- The corruption and its consequences are confined to the kernel's own security authority; there is no VM, IOMMU, or sandbox boundary crossed. This is standard in-kernel privilege escalation territory.
- C:HConfidentiality impact, high
- The caller dereferences a verifier-blessed but JIT-corrupted pointer, giving a BPF_LDX read at an attacker-influenced wild address that can land in mapped kernel memory (vmemmap/KFENCE region for bit31-set values); the loaded bytes can be stashed into a BPF map and read out from userspace, yielding kernel memory disclosure.
- I:HIntegrity impact, high
- The identical primitive works in the store direction — BPF_STX/BPF_ST through the corrupted R0 writes fully attacker-controlled 8-byte values at an attacker-chosen displacement, an out-of-bounds kernel write leverageable for control-flow hijacking.
- A:HAvailability impact, high
- The upstream commit documents a confirmed kernel panic at the ld.bu instruction from the in-tree verifier test, and the wild-pointer dereference reliably oopses whenever the corrupted address is unmapped.