Look up another CVE · open CVE-2025-38261 in the interactive tracker
CVE-2025-38261
riscv: save the SR_SUM status over switches
Published 2025-07-09 (15 months ago) by the Linux kernel CNA. Subsystem arch/riscv. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-38261 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 | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When threads/tasks are switched we need to ensure the old execution's SR_SUM state is saved and the new thread has the old SR_SUM state restored. The issue was seen under heavy load especially with the syz-stress tool running, with crashes as follows in schedule_tail: Unable to handle kernel access to user memory without uaccess routines at virtual address 000000002749f0d0 Oops [#1] Modules linked in: CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 Hardware name: riscv-virtio,qemu (DT) epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 ra : task_pid_vnr include/linux/sched.h:1421 [inline] ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264 epc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0 gp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000 t1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0 s1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003 a2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00 a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba s2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0 s5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850 s8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8 s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2 t5 : ffffffc4043cafba t6 : 0000000000040000 status: 0000000000000120 badaddr: 000000002749f0d0 cause: 000000000000000f Call Trace: [<ffffffe00008c8b0>] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 [<ffffffe000005570>] ret_from_exception+0x0/0x14 Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace b5f8f9231dc87dda ]--- The issue comes from the put_user() in schedule_tail (kernel/sched/core.c) doing the following: asmlinkage __visible void schedule_tail(struct task_struct *prev) { ... if (current->set_child_tid) put_user(task_pid_vnr(current), current->set_child_tid); ... } the put_user() macro causes the code sequence to come out as follows: 1: __enable_user_access() 2: reg = task_pid_vnr(current); 3: *current->set_child_tid = reg; 4: __disable_user_access() The problem is that we may have a sleeping function as argument which could clear SR_SUM causing the panic above. This was fixed by evaluating the argument of the put_user() macro outside the user-enabled section in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before enabling user access")" In order for riscv to take advantage of unsafe_get/put_XXX() macros and to avoid the same issue we had with put_user() and sleeping functions we must ensure code flow can go through switch_to() from within a region of code with SR_SUM enabled and come back with SR_SUM still enabled. This patch addresses the problem allowing future work to enable full use of unsafe_get/put_XXX() macros without needing to take a CSR bit flip cost on every access. Make switch_to() save and restore SR_SUM.
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/riscv/include/asm/processor.h
arch/riscv/kernel/asm-offsets.c
arch/riscv/kernel/entry.S
- What this is
- RISC-V ARCHITECTUREMAINTAINERS section matched on arch/riscv/ · linux-riscv@lists.infradead.org · Supported
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2025-07-09 (15 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.16%, higher than 5.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/riscv
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.15 | 6.15.5 | 69ea599a8dab |
| 4.15 | 6.16 | 788aa64c01f1 |
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
- The vulnerable code is the RISC-V context switch, reached only by executing code on the machine — ordinary syscalls such as clone(), read()/write() with partially-mapped buffers, or futex operations. There is no network-facing path to __switch_to.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: an unprivileged process can pin threads to a single CPU with sched_setaffinity and drive clone()/uaccess-heavy syscalls to force a context switch inside a SUM-enabled window, which is exactly the syz-stress workload that produced the reported oops. No condition depends on state outside the attacker's influence.
- PR:LPrivileges required, low
- Only the ability to run unprivileged code is needed — the trigger paths (fork/clone reaching schedule_tail's put_user, copy_to_user/copy_from_user, futex) are available to any user with no capability, namespace, or filesystem gate. The original reporter's syz-executor process hit it as a plain unprivileged task.
- UI:NUser interaction, none
- The attacker triggers the condition entirely through their own syscalls and scheduling pressure. No victim action, mount, or file open is required.
- S:UScope, unchanged
- Both the vulnerable component and the impacted component are the kernel itself; although SUM leaks across task contexts, that remains within a single security authority. No hypervisor, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- A stale SR_SUM left set means kernel code in an unrelated task executes with S-mode access to U-mode pages enabled — the RISC-V SMAP equivalent disabled — which the maintainers explicitly labelled a vulnerability in the sibling fix c08b4848f596. Combined with attacker-controlled user mappings this yields an arbitrary kernel-side read primitive against attacker-authored data.
- I:HIntegrity impact, high
- The same protection bypass is symmetric: with SUM erroneously set, kernel stores to user-range addresses succeed silently, giving a write primitive that converts any kernel wild/NULL pointer dereference into controlled memory corruption and privilege escalation.
- A:HAvailability impact, high
- The opposite direction — resuming with SUM unexpectedly cleared inside a uaccess window — reaches die_kernel_fault("access to user memory without uaccess routines") in arch/riscv/mm/fault.c, the exact schedule_tail oops in the report. Dying in the scheduler tail destabilises the runqueue, and with panic_on_oops set it is an outright kernel panic.