Description
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.
Published: 2026-09-16
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: System instability and denial of service due to per‑CPU register corruption in the LoongArch kernel
Action: Apply Patch
AI Analysis

Impact

The flaw lies in the LoongArch rethook trampoline, which incorrectly preserves the $r21 register that holds the CPU’s per‑CPU base address. When a task migrates to another core while the trampoline is executing, the stale $r21 value is restored, poisoning the register on the new core. This leads to accesses to incorrect per‑CPU data structures, corrupting the scheduler, timers, and RCU paths, and can cause hard lockups under heavy kretprobe usage. The vulnerability does not currently allow arbitrary code execution, but it results in critical system instability and denial of service. The weakness can be classified as improper initialization of a critical register.

Affected Systems

All Linux kernels running on LoongArch architecture are potentially affected, with the issue demonstrated on a Loongson‑3A6000 platform. The impact is triggered when kretprobes are heavily used (e.g., file‑system paths) under a pre‑emptible load. No vendor‑specific product list exists beyond the generic Linux:Linux identification.

Risk and Exploitability

The CVSS score of 7.8 marks this flaw as high severity. The EPSS score is below 1 %, indicating a very low probability of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog, implying no known widespread exploitation. Attackers would need to execute code that triggers heavy kretprobe activity, such as installing large amounts of software or performing extensive file operations, to induce the fault. Under those conditions the kernel can lock up, denying service to all users on the affected system.

Generated by OpenCVE AI on September 18, 2026 at 03:46 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the upstream kernel patch that removes the save and restore of the $r21 register from the rethook trampoline.
  • Recompile the kernel with the patched source and deploy the updated kernel to all LoongArch machines.
  • Ensure that the updated kernel is running before performing any workloads that heavily use kretprobes, such as large file system operations or application installs.

Generated by OpenCVE AI on September 18, 2026 at 03:46 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Fri, 18 Sep 2026 04:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description 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.
Title LoongArch: Do not save/restore percpu base register in rethook trampoline
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:39:51.967Z

Reserved: 2026-09-11T19:38:34.774Z

Link: CVE-2026-89903

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:16:59.257

Modified: 2026-09-16T15:18:16.433

Link: CVE-2026-89903

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T04:00:03Z

Weaknesses