CVE-2026-99223 in Linux
Riassunto
di VulDB • 02/11/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
keys: rendere gli indici dei portachiavi indipendenti dagli indirizzi del kernel
KEYCTL_READ restituisce i numeri di serie presenti in un portachiavi ordinati secondo il traversal dell'array associativo. La prima parola dell'indice è un hash pubblico e deterministico derivato dal puntatore al tipo, dal puntatore al dominio e dalla descrizione. Un utente non privilegiato può quindi inserire chiavi con descrizioni note, prevederne l'ordine per ogni possibile offset di KASLR (Kernel Address Space Layout Randomization) e recuperare l'indirizzo dell'immagine del kernel. Su una build x86-64 con un allineamento di 16 MiB, sono sufficienti 45 chiavi utente per distinguere gli offset candidati.
Rimuovere gli indirizzi dall'intero indice, non solo dalla prima parola hash. Assegnare a ciascun tipo e dominio di chiave un ID a 64 bit diverso da zero ed eseguire l'hashing di tali ID insieme alla descrizione utilizzando una chiave SipHash inizializzata una sola volta. Utilizzare anche i full IDs nei blocchi successivi dell'indice. La troncatura o l'hashing degli ID in queste sezioni comporterebbe la perdita della garanzia che tuple distinte di tipo/dominio/descrizione abbiano un bit dell'indice differente.
Assegnare gli ID in modo lazy (pigro), poiché i tipi di chiave privati non devono essere registrati. Memorizzarli nella chiave dell'indice affinché le traversate degli alberi e le copie di un indice esistente non debbano dereferenziare un descrittore di tipo che potrebbe essere stato disregistrato. Mantenere coerenti il layout a blocchi da 32 bit e gli offset dei bit in diff_objects(), e conservare lo slot radice separato per i portachiavi utilizzati nella ricerca ricorsiva. Il confronto delle chiavi, le autorizzazioni e il formato dei dati userspace rimangono invariati; viene sostituito solo l'ordinamento in memoria dipendente dagli indirizzi.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.