CVE-2026-31402

Riepilogo

Nel kernel Linux è stata risolta la seguente vulnerabilità: nfsd: corretto heap overflow nella cache di replay LOCK NFSv4.0 La cache di replay NFSv4.0 utilizza un buffer inline fisso di 112 byte (rp_ibuf[NFSD4_REPLAY_ISIZE]) per memorizzare le risposte delle operazioni codificate. Questa dimensione è stata calcolata in base alle risposte OPEN e non tiene conto delle risposte di diniego LOCK, che includono il proprietario del lock in conflitto come campo a lunghezza variabile fino a 1024 byte (NFS4_OPAQUE_LIMIT). Quando un'operazione LOCK viene negata a causa di un conflitto con un lock esistente che ha un proprietario 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ò comporta una scrittura slab-out-of-bounds fino a 944 byte oltre la fine del buffer, corrompendo la memoria heap adiacente. Questo può essere innescato da remoto da un attaccante non autenticato con due client NFSv4.0 cooperanti: uno imposta un lock con una stringa del proprietario di grandi dimensioni, poi l'altro richiede un lock in conflitto per provocare il diniego. Potremmo risolvere questo problema aumentando NFSD4_REPLAY_ISIZE per consentire un opaco completo, ma ciò aumenterebbe la dimensione di ogni stateowner, quando la maggior parte dei lockowner non è così grande. Invece, risolviamo il problema controllando 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 la memorizzazione nella cache del payload di replay. Lo stato viene comunque memorizzato nella cache e il client ha già ricevuto la risposta corretta sulla richiesta originale.

• CVE-2026-31402Informativo

  CVE-2026-31402