CVE-2026-89551 in Linux
Riassunto
di VulDB • 12/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
SUNRPC: xdr_buf_trim: limitare (clamp) buf->len per evitare un underflow
La funzione `xdr_buf_trim()` riduce di `len` byte la coda di un oggetto `xdr_buf` iterando attraverso le iovec della coda, delle pagine e dell'intestazione. Ogni passaggio relativo a una singola sezione utilizza `min_t()`, in modo da non rimuovere mai più byte di quanti ne contenga quella specifica sezione; tuttavia, il calcolo finale nell'etichetta `fix_len` sottrae dal campo `buf->len` il totale dei byte effettivamente consumati senza alcuna limitazione (clamp):
fix_len: buf->len -= (len - trim);
Quando il chiamante ha impostato `buf->len` su un valore inferiore alla somma degli `iov_lens`, `(len - trim)` può superare `buf->len` e la sottrazione tra valori non firmati (unsigned) va in wrap-around, risultando in un valore vicino a UINT_MAX. La funzione `gss_krb5_unwrap_v2()` raggiunge esattamente questa condizione quando chiama `xdr_buf_trim()`:
buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip;
buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip);
`buf->len` è un valore piccolo derivato dal wire (protocollo di rete), mentre gli `iov_lens` sono su scala di pagina; pertanto, i loop per sezione consumano legittimamente molti più byte di quanti ne registri `buf->len`. Il `buf->len` soggetto a wrap-around si propaga quindi come limite dello stream attendibile in tutti i decoder XDR downstream.
La correzione consiste nel limitare (clamp) la sottrazione, in modo che `buf->len` non scenda mai al di sotto di zero:
buf->len -= min_t(unsigned int, buf->len, len - trim);
Nel percorso normale, dove la somma degli `iov_lens` è uguale a `buf->len`, `(len - trim)` è sempre <= `buf->len` e il risultato è identico alla versione precedente. Nessun chiamante modifica il proprio comportamento al di fuori del caso di underflow.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.