CVE-2026-89665
Riassunto
di VulDB • 11/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
nfsd: rifiutare i valori di useconds fuori intervallo in NFSv2 SETATTR/CREATE
Il decoder sattr per NFSv2 converte gli useconds della rete in nanosecondi in svcxdr_decode_sattr():
iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;
tmp2 è un u32 e NSEC_PER_USEC vale 1000, quindi il prodotto viene calcolato come unsigned long. Su architetture ILP32 questo tipo ha una dimensione di 32 bit, e un valore di useconds fuori intervallo, ad esempio 4294968, va in overflow su tv_nsec == 704. La corruzione avviene quindi durante la fase di decode, prima che qualsiasi funzione proc possa ispezionare il valore; una successiva verifica dell'intervallo su tv_nsec rileverebbe un risultato all'interno dei limiti accettabili e lo accetterebbe. Il rifiuto nella fase di decoder restituisce una risposta RPC GARBAGE_ARGS. NFSv2 non definisce NFSERR_INVAL, quindi non esiste uno stato a livello NFS da restituire per un argomento temporale malformato, e il controllo non può essere spostato alla funzione proc come avviene per i controlli dell'intervallo nsec nelle versioni v3/v4.
Proteggere gli useconds grezzi prima della moltiplicazione e rifiutare i valori superiori a 1000000. Il valore useconds == 1000000 viene mantenuto: è la convenzione Sun per "impostare all'ora corrente del server", e il client NFSv2 Linux nel repository lo emette sia nel campo atime che in quello mtime per un semplice touch / utimes(file, NULL) (vedere encode_sattr() e xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rifiutare 1000000 trasformerebbe questa operazione comune in un fallimento di decode irreversibile sia per SETATTR che per CREATE. 1000000 * NSEC_PER_USEC è pari a 10^9, che non va in overflow su ILP32, quindi il valore della convenzione Sun passa senza problemi. Vengono rifiutati solo i valori genuinamente fuori intervallo (> 1000000). I controlli per atime e mtime sono pertanto simmetrici.
Il decoder applicava la convenzione Sun solo nel blocco mtime, che cancella ATTR_ATIME_SET|ATTR_MTIME_SET quando gli useconds di mtime sono uguali a 1000000. Se un client inserisce 1000000 nel campo atime ma non in quello di mtime, il blocco atime memorizzava un tv_nsec fuori intervallo (10^9) e lasciava ATTR_ATIME_SET impostato, consentendo al filesystem di ricevere il valore errato. Applicare la convenzione anche nel blocco atime, cancellando ATTR_ATIME_SET affinché il server utilizzi la propria ora corrente ignorando il valore fornito. Vengono cancellati solo i flag ATTR_ATIME_SET. Il blocco mtime mantiene il suo comportamento esistente, dove 1000000 significa "impostare sia atime che mtime all'ora attuale".
[ cel: varie modifiche, aggiunte e pulizie ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.