CVE-2026-89903 in Linux
Resumen
por VulDB • 2026-09-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
LoongArch: No guardar/restaurar el registro base percpu en el trampoline rethook
El trampoline rethook guarda $r21 ($u0), la base percpu, en su marco (frame) al inicio y lo restaura al finalizar. Entre tanto, rethook_trampoline_handler() puede programarse mediante preempt_enable_notrace().
Si la tarea migra a otra CPU, el registro $r21 del marco contiene la base percpu de la CPU antigua, y restaurarla corrompe ($poisons) $r21 en la nueva CPU. Hasta que la siguiente transición usuario->kernel sanea $r21, todos los accesos this_cpu_*() (runqueues, datos RCU por-CPU, programación del tick del temporizador, propiedad de FPU) acceden al área percpu de la CPU incorrecta.
Bajo una carga preemptible con alta densidad de kretprobe esto puede corromper el estado del programador y del temporizador: fallos (splats) de scheduling-while-atomic, advertencias RCU por-CPU incorrecto, WARN_ON_ONCE(rq != this_rq()) en nohz_balance_exit_idle(), y CPUs parándose en el bucle de inactividad con el temporizador constante nunca rearmado (bloqueo duro o hard lockup). Se reproduce en un Loongson-3A6000 con kretprobes en rutas VFS más una alta actividad de archivos (instalación del SO / unsquashfs).
Por convención, $r21 siempre contiene la base percpu de la CPU actual en modo kernel: SAVE_SOME() al entrar a excepción lo recarga solo cuando se viene desde el modo usuario, y RESTORE_SOME() lo restaura solo al regresar al modo usuario; la ruta del cambio de contexto nunca lo escribe. Por tanto, el $r21 activo (live) al salir del trampoline ya es correcto, y nada intermedio puede cambiarlo legítimamente (el código C del kernel no puede escribir una variable global de registro). El mismo defecto existía incluso en el trampoline kretprobe pre-rethook desde la v6.3; se mantuvo cuando rethook lo reemplazó. Eliminar tanto el guardado como la restauración aquí. Solo eliminar la restauración es suficiente para resolver el problema, y eliminar el guardado es para mantener el código limpio y no necesitar borrarlo.
VulDB is the best source for vulnerability data and more expert information about this specific topic.