EUVD-2026-80503
GHSA-fx3m-r2wg-wx6v
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local-only, LoongArch-specific; kretprobe installation needs root-equivalent privilege (PR:H); triggering needs a preemption+CPU-migration race (AC:H); impact is availability-dominant (A:H) with no real confidentiality (C:N) and only incidental state corruption (I:L).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
7DescriptionCVE.org
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.
AnalysisAI
A race in the LoongArch rethook/kretprobe trampoline allows the per-CPU base register ($r21/$u0) to be restored with a stale value after a probed task is preempted and migrated to a different CPU, causing this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) to hit the wrong CPU's percpu area and ultimately corrupting scheduler and timer state. The result under heavy kretprobe load is scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and in the worst case a CPU parking in the idle loop with its timer never re-armed, i.e. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation is limited to the LoongArch architecture (the flaw is in the LoongArch rethook trampoline's save/restore of the $r21/$u0 percpu base register) and requires a preemptible kernel plus active use of kretprobes/rethook on frequently-called functions (the description cites kretprobes on VFS paths). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a LoongArch-specific kernel race (CWE-366/362) in the rethook/kretprobe trampoline that manifests as scheduler and timer-state corruption and, at worst, a hard lockup - a denial-of-service, not the confidentiality/integrity compromise the vendor triad implies. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patch: upgrade to Linux 6.6.157, 6.12.110, 6.18.51, 7.2.5, or 7.3-rc2 (or a later release in the corresponding stable line), which drop both the save and the restore of $r21 in the LoongArch rethook trampoline; the fixes are mirrored at https://git.kernel.org/stable/c/a03b5e7483ad2c33ba5dd2adb8552e84bfee8fe2, https://git.kernel.org/stable/c/8f15e95b438bc6b3c9f23a33c9a0d0678ebd1dc8, https://git.kernel.org/stable/c/266ffc92e68593759adfe3d58f188773d32782c3, https://git.kernel.org/stable/c/c048b0a3c0836c4b1bef4b51d355d27090bf6790, and https://git.kernel.org/stable/c/c3f2feace5e4f4b01b68b9f947b19adb4155c32e. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all LoongArch hosts and determine which run preemptible kernels with active kretprobes/rethook instrumentation (tracing, eBPF, observability agents), and confirm root-equivalent access to those systems is restricted and audited; for any identified host, schedule the vendor-released kernel update from the advisory rather than the upstream base version, since patch status is 'Patch available per vendor advisory' and no exact fixed version was supplied. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today