CVE-2025-22048 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Don't override subprog's return value
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).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability CVE-2025-22048 affects the Linux kernel's LoongArch architecture implementation of eBPF (extended Berkeley Packet Filter) functionality. This issue stems from improper handling of return values during BPF function calls, specifically when dealing with bpf2bpf calls versus native calls. The problem manifests in the BPF verifier's behavior when processing memory access operations, particularly the ld.bu instruction which attempts to load a byte from a memory address returned by a subprogram. The root cause lies in the kernel's handling of register values during function call propagation, where the implementation incorrectly sign-extends return values in a way that conflicts with BPF's expected zero-extended return value conventions. This vulnerability falls under the CWE category of improper handling of return values and can be mapped to ATT&CK technique T1059.006 for execution through system calls and T1566.001 for initial access via kernel exploits.
The technical flaw occurs at the instruction level where the LoongArch BPF implementation processes function calls with incorrect register propagation. During the commit 73c359d1d356 changes, the kernel introduced sign-extension of return values from the a5 register to a0 register, which is appropriate for native function calls where sign extension is required. However, this same logic is applied to BPF-to-BPF calls where the expected behavior is zero-extension of return values in the a5 register. The ld.bu instruction triggers a panic because it attempts to access memory using an address that has been incorrectly sign-extended rather than properly zero-extended. This creates a mismatch between the expected memory address format and the actual value stored in the register, leading to invalid memory access patterns. The verifier test case `calls: div by 0 in subprog` specifically targets this scenario by creating a condition where the incorrect register handling causes the system to attempt division by zero during memory access operations, resulting in kernel panic.
The operational impact of this vulnerability is significant as it can lead to system crashes and potential denial of service conditions within kernel space. When the BPF verifier encounters a function call that triggers this bug, the kernel will panic and require system reboot, disrupting services and potentially allowing adversaries to exploit this condition for privilege escalation or system compromise. The vulnerability affects systems running Linux kernels with LoongArch architecture support and BPF functionality enabled, particularly those utilizing BPF programs that make function calls. Attackers could potentially craft malicious BPF programs that trigger this condition to cause system instability or gain elevated privileges within the kernel space. The nature of the vulnerability makes it particularly dangerous in containerized environments or systems where BPF is extensively used for network filtering, monitoring, or security policy enforcement.
Mitigation strategies for CVE-2025-22048 should focus on implementing the corrected register propagation logic that distinguishes between native calls and BPF-to-BPF calls. The fix requires modifying the kernel code to only propagate the a0 register back to a5 register for native calls while preserving the original zero-extended value in a5 for BPF-to-BPF calls. System administrators should apply the relevant kernel patches as soon as they become available, ensuring that all LoongArch systems running affected kernel versions receive the necessary updates. Additionally, monitoring for BPF program execution and memory access patterns can help detect potential exploitation attempts. Organizations should also consider implementing kernel lockdown mechanisms and restricting BPF program loading capabilities where possible. The fix aligns with security best practices for kernel-level memory management and register handling, addressing the fundamental issue of improper return value propagation in the BPF execution environment while maintaining compatibility with existing legitimate BPF functionality.