CVE-2026-89903: LoongArch: Do not save/restore percpu base register in rethook trampoline
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Do not save/restore percpu base register in rethook trampoline
The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethooktrampolinehandler() may schedule via preemptenablenotrace().
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 thiscpu() 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, WARNONONCE(rq != thisrq()) in nohzbalanceexitidle(), 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: SAVESOME() at exception entry reloads it only when coming from user mode, and RESTORESOME() 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (LoongArch)to a version that resolves this vulnerability.Fixed in v6.3 - Configuration
Apply the LoongArch fix: inbetween rethook_trampoline_handler() and the rethook trampoline, remove saving $r21 (percpu base) into the trampoline frame and remove restoring it on exit; rely on $r21 being correct at entry/exit so it is not corrupted across CPU migration.
Linux kernel LoongArch rethook/kretprobe trampoline Do not save/restore percpu base register ($r21) in rethook trampoline = Do not save/restore $r21 in rethook trampoline frames (drop save; drop restore)
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
The issue affects LoongArch Linux kernel systems where rethook trampoline handling can run and a task can migrate CPUs while executing it. The reported reproduction used a Loongson-3A6000 system with kretprobes placed on VFS paths under heavy file activity.
What conditions are needed to trigger the corruption?
A rethook trampoline handler must schedule through preempt_enable_notrace(), allowing the task to migrate to another CPU before the trampoline restores register $r21. Kretprobe-heavy, preemptible workloads increase the likelihood of reaching this condition.
How might an administrator recognize an affected system?
Reported signs include scheduling-while-atomic messages, wrong-CPU RCU warnings, and WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(). Systems may also leave CPUs parked in the idle loop because the constant timer is not re-armed, resulting in a hard lockup.