Cloudanix VulnDB

CVE-2025-22069

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Apr 16, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how the Linux kernel on RISC-V processors handles tracing information can let local users crash the system or potentially gain higher privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Stack layout mismatch in RISC-V ftrace return path causes ftrace_return_to_handler to read an incorrect frame pointer from __arch_ftrace_regs, resulting in kernel warning or memory corruption during function graph tracing.

Why it matters to the business

Local users on affected RISC-V Linux systems can trigger kernel warnings or crashes when ftrace or dynamic events are enabled, leading to denial of service or potential privilege escalation in tracing workloads; high ecosystem prevalence of the kernel increases exposure for servers and embedded devices.

How an attack unfolds

An attacker with local access enables function graph tracing or dynamic events, triggers a return probe on a common syscall such as nanosleep, and the mismatched stack layout causes the kernel to dereference an invalid frame pointer, producing a warning or exploitable corruption condition.

How to fix it

Upgrade the Linux kernel to version 6.14.2 or apply commit 78b39c587b8f6c69140177108f9c08a75b1c7c37; rebuild and reboot with the fixed kernel; disable ftrace/function_graph when not required as a temporary mitigation.

How to confirm the fix worked

Confirm kernel version is at least 6.14.2, reproduce the original LTP ftrace_stress_test or dynamic event commands and verify absence of the Bad frame pointer warning, and inspect fgraph.c around ftrace_return_to_handler for the corrected stack layout.

Typical attack path

  1. Obtain local shell on RISC-V Linux system
  2. Write a dynamic event or enable fprobes/function_graph tracer
  3. Invoke a traced function that returns through return_to_handler
  4. Trigger kernel warning or corrupt stack state for further exploitation

How to detect it

Search kernel logs for 'Bad frame pointer' warnings originating from ftrace_return_to_handler, inspect audit or syslog entries showing ftrace or dynamic_events activation followed by the warning, and review process execution of sleep or LTP trace tests that coincide with the stack mismatch error.

  • Bad frame pointer: expected
  • ftrace_return_to_handler+0x1b2/0x1be
  • from func do_nanosleep return to
  • WARNING: CPU.*at kernel/trace/fgraph.c:755

What your security team should do

  • Immediately upgrade all RISC-V Linux kernels to 6.14.2 or later
  • Audit systems for unnecessary ftrace or fprobe usage and restrict to privileged users only
  • Monitor for kernel warnings containing ftrace_return_to_handler until patches are deployed
  • Prioritize patching on production servers and embedded devices given high kernel prevalence

The record

In the Linux kernel, the following vulnerability has been resolved: riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler Naresh Kamboju reported a "Bad frame pointer" kernel warning while running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the same issue with the following command: ``` $ cd /sys/kernel/debug/tracing $ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` And we can get the following kernel warning: [ 127.692888] ------------[ cut here ]------------ [ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000 [ 127.693755] from func do_nanosleep return to ffffffff800ccb16 [ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be [ 127.699894] Modules linked in: [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32 [ 127.701453] Hardware name: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10 [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000 [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80 [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20 [ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000 [ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0 [ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068 [ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001 [ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e [ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18 [ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 127.703292] [<ffffffff8013b5e0>] ftrace_return_to_handler+0x1b2/0x1be [ 127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26 [ 127.704009] [<ffffffff80017bb8>] return_to_handler+0x0/0x26 [ 127.704057] [<ffffffff800d3352>] common_nsleep+0x42/0x54 [ 127.704117] [<ffffffff800d44a2>] __riscv_sys_clock_nanosleep+0xba/0x10a [ 127.704176] [<ffffffff80901c56>] do_trap_ecall_u+0x188/0x218 [ 127.704295] [<ffffffff8090cc3e>] handle_exception+0x14a/0x156 [ 127.705436] ---[ end trace 0000000000000000 ]--- The reason is that the stack layout for constructing argument for the ftrace_return_to_handler in the return_to_handler does not match the __arch_ftrace_regs structure of riscv, leading to unexpected results.

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 No fix
Debian:14 linux 0 6.16.3-1
Linux Kernel 6.14.0 6.14.2

Related vulnerabilities