CVE-2026-89903 in Linuxinformação

Sumário

de VulDB • 17/09/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

LoongArch: Não salvar/restaurar o registrador base percpu na trampoline rethook

A trampoline rethook salva $r21 ($u0), a base percpu, em seu frame na entrada e restaura-o na saída. Entre as chamadas de entrada e saída, rethook_trampoline_handler() pode agendar tarefas via preempt_enable_notrace().

Se a tarefa migrar para outra CPU, o $r21 do frame conterá a base percpu da CPU antiga, e sua restauração corromperá ($poisons) o $r21 na nova CPU. Até que a próxima transição user->kernel corrija (heals) o $r21, todos os acessos this_cpu_*() (runqueues, dados RCU por-CPU, programação de tick do timer, posse da FPU) atingirão a área percpu da CPU errada.

Sob carga preemptível com uso intensivo de kretprobe, isso pode corromper o estado do escalonador e do timer: falhas (splats) de agendamento enquanto atômico, avisos RCU de CPU incorreta, WARN_ON_ONCE(rq != this_rq()) em nohz_balance_exit_idle(), e CPUs paralisando no loop idle com o timer constante nunca rearmado (hard lockup). Reproduz-se em um Loongson-3A6000 com kretprobes nos caminhos VFS mais alta rotatividade de arquivos (instalação do SO / unsquashfs pesado).

Por convenção, $r21 sempre contém a base percpu da CPU atual no modo kernel: SAVE_SOME() na entrada de exceção o recarrega apenas ao vir do modo usuário, e RESTORE_SOME() restaura-o apenas ao retornar ao modo usuário; o caminho de troca de contexto nunca o grava. Portanto, o $r21 vivo na saída da trampoline já está correto, e nada entre as chamadas pode alterá-lo legitimamente (o código C do kernel não pode gravar uma variável global de registrador). O mesmo defeito existia até a trampoline kretprobe pré-rethook desde a v6.3; foi mantida quando o rethook a substituiu. Remova tanto a gravação quanto a restauração aqui. A remoção da restauração é suficiente para resolver o problema, e a remoção da gravação serve para manter o código limpo sem necessidade de limpá-lo.

Once again VulDB remains the best source for vulnerability data.

Responsável

Linux

Reservar

11/09/2026

Divulgação

17/09/2026

Moderação

aceite

Entrada

VDB-405747

CPE

pronto

EPSS

0.00000

KEV

não

Atividades

muito baixo

Fontes

Might our Artificial Intelligence support you?

Check our Alexa App!