Look up another CVE · open CVE-2026-89903 in the interactive tracker
CVE-2026-89903
LoongArch: Do not save/restore percpu base register in rethook trampoline
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem arch/loongarch. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89903 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it.
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/loongarch/kernel/rethook_trampoline.S
- What this is
- LOONGARCHMAINTAINERS section matched on arch/loongarch/ · loongarch@lists.linux.dev · Maintained
Check it on the machine
grep -w CONFIG_RETHOOK /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixieYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae
- bookworm · linux-6.12Ynot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- ?
- not established - no Makefile entry for the affected file
- Y
- built in where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_RETHOOK
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 kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days 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.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/loongarch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.3 | 6.6.157 | a03b5e7483ad |
| 6.3 | 6.12.110 | 8f15e95b438b |
| 6.3 | 6.18.51 | 266ffc92e685 |
| 6.3 | 7.2.5 | c048b0a3c083 |
| 6.3 | 7.3 | c3f2feace5e4 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 rethook trampoline runs only after a locally installed kretprobe fires on a kernel function return (tracefs kprobe_events, perf kprobe PMU, or BPF kretprobe). It is not reached by receiving network packets or by a network-server protocol parser.
- AC:LAttack complexity, low
- The attacker installs a kretprobe on a function they call (e.g. VFS) and forces the migration window: a helper thread can sched_setaffinity or generate preemption so preempt_enable_notrace() in rethook_trampoline_handler() reschedules onto another CPU before $r21 is restored.
- PR:LPrivileges required, low
- Creating kretprobes via kprobe_events checks only LOCKDOWN_TRACEFS and DAC (0640), not capable(); tracing-group gid mounts on Android/ChromeOS/dev systems grant this to unprivileged users. CAP_BPF/CAP_PERFMON for BPF kretprobe attach are likewise Low because BPF tokens can delegate them.
- UI:NUser interaction, none
- The attacker installs and enables the kretprobe, then triggers matching returns and CPU migration from their own threads. No separate victim mount, click, or other interactive action is required.
- S:UScope, unchanged
- Restoring a stale percpu base corrupts this kernel's per-CPU areas (runqueues, RCU, timers, FPU owner) on the same host. That is in-kernel memory corruption, not a guest-to-host, IOMMU, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- Poisoned $r21 makes this_cpu_read() fetch another CPU's per-CPU data, including FPU ownership used to decide whether to save/restore vector state, so register contents can leak across tasks. Kernel memory corruption of this kind is a High confidentiality primitive.
- I:HIntegrity impact, high
- this_cpu_write() and related RMWs then modify the other CPU's scheduler, timer, and RCU per-CPU objects, including structures that hold function pointers (timer callbacks, sched class). That is kernel memory corruption enabling integrity loss and control-flow hijack.
- A:HAvailability impact, high
- The same wrong-CPU accesses cause scheduling-while-atomic splats, wrong-CPU RCU warnings, rq != this_rq() WARNs, and idle CPUs whose constant timer is never re-armed, producing oops, panic, or hard lockup as documented in the fix.