Cloudanix VulnDB

CVE-2025-22048

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Apr 16, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel on certain hardware can cause the computer to crash when running some specialized programs that extend kernel functionality.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect sign-extension of return values from BPF subprograms on LoongArch causes the verifier to propagate a0 back to a5 for bpf2bpf calls, resulting in an invalid memory address load and kernel panic.

Why it matters to the business

Systems running affected kernels on LoongArch hardware may experience unexpected crashes when loading or executing certain eBPF programs, leading to downtime and potential loss of service in environments that rely on BPF for networking, security, or observability.

How an attack unfolds

An attacker supplies a crafted BPF program containing a subprogram whose return value is later dereferenced; the flawed register propagation leaves a5 holding a sign-extended address instead of the zero-extended value expected by the subprogram, causing the ld.bu instruction to fault.

How to fix it

Upgrade the Linux kernel to version 6.6.87 or later, or apply the commit 7df2696256a034405d3c5a71b3a4c54725de4404. For Red Hat Enterprise Linux 9.0 E4S systems, update tigervnc packages to version 0:1.11.0-22.el9_0.12 or newer.

How to confirm the fix worked

Verify the running kernel version is at or above the fixed release; confirm the git commit is present in the kernel source tree; re-run the verifier test "calls: div by 0 in subprog" to ensure it no longer panics.

Typical attack path

  1. Compile or load a BPF program containing a subprogram that returns a pointer value
  2. Trigger the verifier path that exercises bpf2bpf calls on LoongArch
  3. Cause the kernel to execute the ld.bu instruction using the corrupted a5 register
  4. Trigger a panic or denial of service

How to detect it

Search kernel logs for panic messages referencing ld.bu or LoongArch BPF register handling; examine audit logs for BPF program loads that coincide with system restarts.

What your security team should do

  • Prioritize kernel upgrades on all LoongArch systems within the next maintenance window
  • Monitor EPSS and KEV status for any future increase in exploit activity
  • Restrict untrusted BPF program loading via kernel.unprivileged_bpf_disabled until patches are applied

The record

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).

Affected packages

Ecosystem Package Introduced Fixed
Debian:12 linux 0 No fix
Debian:13 linux 0 No fix
Debian:13 linux 0 6.12.25-1
Linux Kernel 0 6.6.87
Mageia:9 kernel 0 6.6.88-3.mga9
Mageia:9 kernel-linus 0 6.6.88-1.mga9
Mageia:9 kmod-virtualbox 0 7.0.24-70.mga9
Mageia:9 kmod-xtables-addons 0 3.24-78.mga9

Related vulnerabilities