Answer in brief
CVE-2026-89903 records a Unknown severity vulnerability in LoongArch: Do not save/restore percpu base register in rethook trampoline. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3f5536860086d906b01ec5ed68cf50c7edcc40af <a03b5e7483ad2c33ba5dd2adb8552e84bfee8fe2 || >=3f5536860086d906b01ec5ed68cf50c7edcc40af <8f15e95b438bc6b3c9f23a33c9a0d0678ebd1dc8 || >=3f5536860086d906b01ec5ed68cf50c7edcc40af <266ffc92e68593759adfe3d58f188773d32782c3 || >=3f5536860086d906b01ec5ed68cf50c7edcc40af <c048b0a3c0836c4b1bef4b51d355d27090bf6790 || >=3f5536860086d906b01ec5ed68cf50c7edcc40af <c3f2feace5e4f4b01b68b9f947b19adb4155c32e | a03b5e7483ad2c33ba5dd2adb8552e84bfee8fe2, 8f15e95b438bc6b3c9f23a33c9a0d0678ebd1dc8, 266ffc92e68593759adfe3d58f188773d32782c3, c048b0a3c0836c4b1bef4b51d355d27090bf6790, c3f2feace5e4f4b01b68b9f947b19adb4155c32e |
| Linux/Linuxgeneric | 6.3 | Not reported |
Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 16, 2026
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.
Quoted source text, attributed separately from HOL analysis.