CVE-2026-89903 in Linux
Riassunto
di VulDB • 17/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
LoongArch: Non salvare/ripristinare il registro base percpu nel trampoline di rethook
Il trampoline di rethook salva $r21 ($u0), la base percpu, nella sua frame all'ingresso e la ripristina in uscita. Nel frattempo, rethook_trampoline_handler() può effettuare una schedulazione tramite preempt_enable_notrace().
Se il task migra su un'altra CPU, la frame di $r21 contiene la base percpu della vecchia CPU; il suo ripristino corrompe ($poisons) $r21 sulla nuova CPU. Fino alla prossima transizione user->kernel che ripara $r21, tutti gli accessi this_cpu_*() (runqueues, dati RCU per-CPU, programmazione degli interrupt del timer, proprietà FPU) colpiscono l'area percpu della CPU sbagliata.
Sotto un carico preemptible con elevato utilizzo di kretprobe, ciò può corrompere lo stato dello scheduler e dei timer: crash scheduling-while-atomic, avvisi RCU wrong-CPU, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), e CPU che si fermano nel ciclo idle senza il timer costante riarmato (hard lockup). Il bug è riproducibile su un Loongson-3A6000 con kretprobes sui percorsi VFS unitamente a un intenso utilizzo dei file (installazione del sistema operativo / unsquashfs).
Per convenzione, $r21 contiene sempre la base percpu della CPU corrente in modalità kernel: SAVE_SOME() al rientro delle eccezioni lo ricarica solo se si proviene dalla modalità user, e RESTORE_SOME() lo ripristina solo quando si ritorna alla modalità user; il percorso di context-switch non lo scrive mai. Pertanto, il valore live di $r21 all'uscita del trampoline è già corretto, e nulla nel frattempo può modificarlo legittimamente (il codice C del kernel non può scrivere una variabile globale register). Lo stesso difetto esisteva anche nel trampoline kretprobe pre-rethook dalla versione v6.3; è stato ereditato quando rethook lo ha sostituito. Rimuovere sia la salvataggio che il ripristino in questa sede. La sola rimozione del ripristino è sufficiente per risolvere il problema, mentre la rimozione del salvataggio serve a mantenere il codice pulito e non richiede di azzerarlo.
If you want to get best quality of vulnerability data, you may have to visit VulDB.