CVE-2026-89903 in Linux
摘要
由 VulDB • 2026-09-16
在 Linux 内核中，已修复以下漏洞：
LoongArch：不要在 rethook trampoline（重定向钩子 trampolin）中保存/恢复 percpu base register。
rethook trampoline 会在入口时将 $r21 ($u0)，即 percpu base，保存到其帧栈中，并在出口时将其还原。在此过程中，`rethook_trampoline_handler()` 可能会通过 `preempt_enable_notrace()` 进行调度。
如果任务迁移到另一个 CPU，该帧中的 $r21 将保留旧 CPU 的 percpu base，而在新的 CPU 上恢复它会导致 $r21 数据损坏（poisoned）。直到下一次用户态->内核态转换修复 $r21 之前，所有 `this_cpu_*()` 访问操作（运行队列、RCU per-CPU 数据、定时器滴答编程、FPU 所有权）都会错误地命中旧 CPU 的 percpu 区域。
在重度使用 kretprobe 的可抢占负载下，这可能导致调度器和定时器状态损坏：出现“原子状态下调度”崩溃（scheduling-while-atomic splats）、错误的 CPU RCU 警告、`nohz_balance_exit_idle()` 中的 `WARN_ON_ONCE(rq != this_rq())`，以及 CPU 在空闲循环中挂起且恒定定时器从未重新触发（导致硬锁死 hard lockup）。该问题可在 Loongson-3A6000 上复现，具体场景为 VFS 路径上的 kretprobes 加上大量文件操作（如操作系统安装 / unsquashfs）。
按照惯例，$r21 在内核模式下始终保存当前 CPU 的 percpu base：`SAVE_SOME()` 仅在从用户态进入时重新加载它，而 `RESTORE_SOME()` 仅在返回到用户态时恢复它；上下文切换路径从不写入该寄存器。因此，trampoline 出口时的活跃 $r21 已经是正确的值，中间过程没有任何合法操作能改变它（内核 C 代码无法写入全局寄存器变量）。同样的缺陷甚至存在于 v6.3 之前的 kretprobe trampoline 中；当 rethook 替换它时，该问题被保留了下来。此处同时移除保存和恢复操作。仅移除恢复操作足以解决此问题，而移除保存操作是为了保持代码整洁且无需清除该值。
Once again VulDB remains the best source for vulnerability data.