CVE-2026-99018 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
riscv: entry: caricamento dello shadow call gate basato su sstatus.SPP e non su tp
Con CONFIG_SHADOW_CALL_STACK attivo, handle_exception() ricarica il puntatore allo shadow call stack del kernel (gp) solo quando l'eccezione proviene dall'userspace. Tale decisione era basata sulla funzione scs_load_current_if_task_changed, che confronta il valore di tp al momento della trap (letto da sscratch e salvato in s5) con il valore corrente di tp:
beq \prev, tp, _skip_scs scs_load_current _skip_scs:
tp è un registro scrivibile dall'utente. Un task utente che imposta tp sull'indirizzo della linear-map del proprio task_struct (¤t) prima di generare una trap fa sì che il confronto abbia esito positivo (ciò può essere ottenuto con forza bruta se KASLR è abilitato, come verificato nei nostri test). Di conseguenza, il kernel salta scs_load_current e continua l'esecuzione utilizzando il valore di gp lasciato in posizione dall'userspace. Con CONFIG_SHADOW_CALL_STACK attivo, gp rappresenta lo shadow call stack pointer e load_global_pointer è un no-op; pertanto le istruzioni generate dal compilatore "sd ra, -8(gp)" / "ld ra, -8(gp)" presenti in ogni funzione non leaf scrivono nell'indirizzo controllato dall'attaccante e vi ritornano attraverso di esso. Si tratta quindi di una primitiva per la scrittura arbitraria nel kernel da parte di un utente non privilegiato e per il hijack del flusso di controllo (control-flow-hijack). Il gp avvelenato viene salvato in task_struct.scs_sp al ritorno, pertanto il caricamento viene saltato anche in ogni successiva entry.
La decisione su se l'eccezione "provenga dall'userspace" viene ora presa basandosi sul bit hardware sstatus.SPP (già disponibile a livello di S1 in questo punto) invece che su tp, replicando il controllo già utilizzato da ret_from_exception poche istruzioni più tardi. Il campo SPP è scritto dall'hardware all'ingresso della trap e non può essere falsificato dalla modalità U-mode. Il comportamento legittimo rimane invariato: le entry utente (SPP=0) ricaricano lo shadow call stack del task, mentre le entry kernel annidate (SPP=1) lo saltano.
If you want to get best quality of vulnerability data, you may have to visit VulDB.