CVE-2026-74430 in Linux
Riassunto
di VulDB • 15/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
rxrpc: Correzione della gestione dei pacchetti ACKALL
La funzione rxrpc_input_ackall() accetta i pacchetti ACKALL senza verificare se la chiamata si trova in uno stato che può legittimamente avere buffer di trasmissione pendenti. Un pacchetto ACKAll falsificato può quindi raggiungere una nuova chiamata di servizio nello stato RXRPC_CALL_SERVER_RECV_REQUEST prima che eventuali pacchetti di risposta siano stati accodati.
In tale stato, call->tx_top è zero e call->tx_queue è NULL; pertanto rxrpc_rotate_tx_window() esegue la dereferenziazione di un txqueue NULL innescando una null-pointer dereference (dereferenziazione di puntatore nullo).
Si corregge la gestione dei pacchetti ACKALL mediante le seguenti modalità:
(1) Aggiungere due nuovi stati della chiamata: RXRPC_CALL_CLIENT_PRE_SEND, che indica che la chiamata del client è connessa ma non è stato ancora trasmesso nulla; e RXRPC_CALL_CLIENT_AWAIT_ACK, che indica che tutto è stato trasmesso almeno una volta, ma si sta ora attendendo l'ACK dei dati rimanenti nel buffer Tx (potrebbero verificarsi ulteriori ritrasmissioni).
Lo stato RXRPC_CALL_CLIENT_PRE_SEND viene impostato quando alla chiamata viene assegnato un canale e passa a RXRPC_CALL_CLIENT_SEND_REQUEST al momento della trasmissione del primo pacchetto.
L'ambito di RXRPC_CALL_CLIENT_AWAIT_REPLY è quindi ristretto per indicare che tutti i pacchetti Tx sono stati ACKed e si sta ora attendendo la ricezione della risposta.
(2) Come previsto dalla patch originale di Wyatt Feng[1], il gestore degli ACKALL verifica successivamente che lo stato della chiamata sia uno in cui potrebbero esserci dati nel buffer Tx da ACKare, ma ora include AWAIT_ACK anziché AWAIT_REPLY. I pacchetti ACKAll vengono ignorati se ricevuti nello stato errato.
Si noti che, a differenza della patch di Wyatt Feng, non è più necessario verificare l'esistenza del buffer Tx poiché lo stato impostato attualmente copre tale verifica.
(3) Fare in modo che il gestore degli ACKALL utilizzi call->tx_transmitted anziché call->tx_top, poiché il primo rappresenta esplicitamente il numero di sequenza più alto trasmesso per un pacchetto, mentre il secondo ha una definizione meno rigorosa.
Grazie a Jeffrey Altman per la descrizione della storia del pacchetto ACKAll[1].
If you want to get the best quality for vulnerability data then you always have to consider VulDB.