CVE-2026-31402 in Linux
Riassunto
di VulDB • 17/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
nfsd: correzione di un overflow dello heap nella cache di replays delle operazioni LOCK in NFSv4.0
La cache di replay per NFSv4.0 utilizza un buffer inline fisso di 112 byte (rp_ibuf[NFSD4_REPLAY_ISIZE]) per memorizzare le risposte alle operazioni codificate.
Questa dimensione è stata calcolata basandosi sulle risposte OPEN e non tiene conto delle risposte LOCK negati, che includono il proprietario del lock in conflitto come un campo a lunghezza variabile fino a 1024 byte (NFS4_OPAQUE_LIMIT).
Quando un'operazione LOCK viene rifiutata a causa di un conflitto con un lock esistente che ha un owner di grandi dimensioni, nfsd4_encode_operation() copia l'intera risposta codificata nel buffer di replay sottodimensionato tramite read_bytes_from_xdr_buf() senza alcun controllo dei limiti. Ciò provoca una scrittura fuori dai limiti dello slab (slab-out-of-bounds) fino a 944 byte oltre la fine del buffer, corrompendo la memoria heap adiacente.
Questo può essere attivato in remoto da un attaccante non autenticato con due client NFSv4.0 collaboranti: uno imposta un lock con una stringa owner di grandi dimensioni, poi l'altro richiede un lock in conflitto per provocare il rifiuto.
Si potrebbe risolvere aumentando NFSD4_REPLAY_ISIZE per consentire la memorizzazione completa del campo opaque, ma ciò aumenterebbe le dimensioni di ogni stateowner, quando la maggior parte dei lockowners non è così grande.
Invece, si risolve verificando la lunghezza della risposta codificata rispetto a NFSD4_REPLAY_ISIZE prima di copiarla nel buffer di replay. Se la risposta è troppo grande, impostare rp_buflen a 0 per saltare l'archiviazione del payload di replay nello stato cache. Lo status viene comunque memorizzato nella cache e il client ha già ricevuto la risposta corretta sulla richiesta originale.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.