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 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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
CVSS 3.1