Look up another CVE · open CVE-2023-52761 in the interactive tracker
CVE-2023-52761
riscv: VMAP_STACK overflow detection thread-safe
Published 2024-05-21 (2 years 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-2023-52761 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.5.13-1 | Update the kernel and reboot. Fixed in 6.5.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.5.13-1 | Update the kernel and reboot. Fixed in 6.5.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.5.13-1 | Update the kernel and reboot. Fixed in 6.5.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to `shadow_stack` temporarily before switching finally to per-cpu `overflow_stack`. If two CPUs/harts are racing and end up in over flowing kernel stack, one or both will end up corrupting each other state because `shadow_stack` is not per-cpu. This patch optimizes per-cpu overflow stack switch by directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`. Following are the changes in this patch - Defines an asm macro to obtain per-cpu symbols in destination register. - In entry.S, when overflow is detected, per-cpu overflow stack is located using per-cpu asm macro. Computing per-cpu symbol requires a temporary register. x31 is saved away into CSR_SCRATCH (CSR_SCRATCH is anyways zero since we're in kernel). Please see Links for additional relevant disccussion and alternative solution. Tested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT` Kernel crash log below Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT Task stack: [0xff20000010a98000..0xff20000010a9c000] Overflow stack: [0xff600001f7d98370..0xff600001f7d99370] CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) epc : __memset+0x60/0xfc ra : recursive_loop+0x48/0xc6 [lkdtm] epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80 gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88 t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0 s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000 a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000 a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90 s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684 s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10 s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4 t5 : ffffffff815dbab8 t6 : ff20000010a9bb48 status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f Kernel panic - not syncing: Kernel stack overflow CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff80006754>] dump_backtrace+0x30/0x38 [<ffffffff808de798>] show_stack+0x40/0x4c [<ffffffff808ea2a8>] dump_stack_lvl+0x44/0x5c [<ffffffff808ea2d8>] dump_stack+0x18/0x20 [<ffffffff808dec06>] panic+0x126/0x2fe [<ffffffff800065ea>] walk_stackframe+0x0/0xf0 [<ffffffff0163a752>] recursive_loop+0x48/0xc6 [lkdtm] SMP: stopping secondary CPUs ---[ end Kernel panic - not syncing: Kernel stack overflow ]---
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/asm-prototypes.h
arch/riscv/include/asm/asm.h
arch/riscv/include/asm/thread_info.h
arch/riscv/kernel/asm-offsets.c
arch/riscv/kernel/entry.S
arch/riscv/kernel/traps.c
- 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
- 2024-05-21 (2 years 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.27%, higher than 17.6% 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.5.13 | 1493baaf09e3 |
| 4.15 | 6.6.3 | eff53aea3855 |
| 4.15 | 6.7 | be97d0db5f44 |
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 path is arch/riscv kernel exception entry (handle_kernel_stack_overflow in entry.S), reached only after a local task overflows its kernel stack—not via network protocols or adjacent-link frames.
- AC:LAttack complexity, low
- An attacker who can drive deep kernel recursion can pin threads to multiple harts and trigger both sides of the shared shadow_stack race, so the race is attacker-controlled rather than dependent on external timing.
- PR:LPrivileges required, low
- Kernel stack overflow can be induced through unprivileged syscall/kernel paths that recurse deeply; the overflow handler itself has no capability check, so a normal local user is sufficient.
- UI:NUser interaction, none
- No victim action is required; the attacker triggers the overflows directly from their own processes.
- S:UScope, unchanged
- Impact stays within the same kernel privilege domain; this is not a VM escape, IOMMU bypass, or other cross-boundary break.
- C:HConfidentiality impact, high
- Concurrent corruption of the shared shadow_stack while another hart executes C code on it can overwrite saved registers and stack frames, yielding a kernel read primitive consistent with memory-corruption impact.
- I:HIntegrity impact, high
- The same stack-frame/register corruption can overwrite return addresses and control state in the overflow path, enabling control-flow hijacking in kernel context.
- A:HAvailability impact, high
- The overflow path panics with "Kernel stack overflow"; the race also causes unpredictable corruption that can oops or hang the system.