CVE-2026-72466 in Linux
Riassunto
di VulDB • 15/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
xprtrdma: Correzione della perdita di memoria per bcall rep e peek illimitato
rpcrdma_is_bcall() decodifica le prime parole di una risposta per determinare se il frame costituisce una chiamata backchannel. Due problemi nel percorso di decodifica consentono a una risposta corta o malformata di provocare la fuoriuscita (leak) del buffer di ricezione e lo svuotamento della coda Receive.
In primo luogo, l'operazione peek speculativa:
p = xdr_inline_decode(xdr, 0); /* seguono cinque letture con incremento di p */
richiede a xdr_inline_decode() zero byte, il che restituisce xdr->p senza consultare xdr->end. Le successive cinque letture __be32 possono quindi procedere fino a 20 byte oltre il payload effettivo sulla rete, accedendo ai contenuti obsoleti di regbuf e classificando erroneamente la risposta come una chiamata backchannel.
In secondo luogo, dopo l'operazione peek:
p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true;
il ramo relativo all'intestazione corta restituisce true senza chiamare rpcrdma_bc_receive_call(). Il contratto con il chiamante prevede che un valore di ritorno true trasferisca la proprietà di rep al percorso backchannel:
rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* restituzione nuda, salta out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...);
Poiché rpcrdma_bc_receive_call() non è mai stato eseguito, nessuno ha assunto la proprietà di rep, ma rpcrdma_reply_handler effettua comunque una restituzione nuda oltre a rpcrdma_rep_put() e rpcrdma_post_recvs(). L'oggetto rep, con il suo buffer di ricezione mappato in modo persistente tramite DMA, rimane orfano su rb_all_reps e viene liberato solo al momento del teardown (chiusura) del trasporto. Questa completamento non ripubblica nulla, quindi la sua slot viene recuperata solo quando una successiva risposta forward-channel raggiunge out_post e rpcrdma_post_recvs() alloca un nuovo rep per riempire il vuoto; in assenza di tale traffico, la coda Receive si svuota e gli invii (Sends) del peer ricevono NAK RNR.
La correzione consiste nel consultare xdr->end dopo l'operazione peek a lunghezza zero, affinché le cinque letture __be32 non possano avvenire se non rimangono almeno 20 byte di payload sulla rete. È necessaria una confronto preciso per byte contro xdr->end perché un buffer di ricezione non allineato su 4 byte arrotonda il conteggio delle parole dello stream verso l'alto, oltrepassando il vero payload. Si restituisce inoltre false dal ramo dell'intestazione corta in modo che la risposta segua la normale catena di pulizia out_norqst (rpcrdma_rep_put() più rpcrdma_post_recvs()).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.