CVE-2026-74430 in Linux
Resumen
por VulDB • 2026-08-16
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
rxrpc: Corrección del manejo de paquetes ACKALL
La función rxrpc_input_ackall() acepta paquetes ACKALL sin verificar si la llamada está en un estado que pueda legítimamente tener buffers de transmisión pendientes. Por lo tanto, un paquete ACKAll forjado puede llegar a una nueva llamada de servicio en RXRPC_CALL_SERVER_RECV_REQUEST antes de que se hayan colgado ningún paquete de respuesta.
En ese estado, call->tx_top es cero y call->tx_queue es NULL, por lo que rxrpc_rotate_tx_window() desreferencia un txqueue nulo y desencadena una desreferenciación a puntero nulo (null-pointer dereference).
Se corrige el manejo de los paquetes ACKALL mediante las siguientes medidas:
(1) Se añaden dos nuevos estados de llamada: RXRPC_CALL_CLIENT_PRE_SEND, que indica que la llamada del cliente está conectada pero aún no se ha transmitido nada; y RXRPC_CALL_CLIENT_AWAIT_ACK, que indica que todo se ha transmitido al menos una vez, pero ahora estamos esperando a que los datos restantes en el buffer Tx sean ACKeados (pueden seguir ocurriendo retransmisiones).
El estado RXRPC_CALL_CLIENT_PRE_SEND se establece cuando se asigna un canal a la llamada y transiciona a RXRPC_CALL_CLIENT_SEND_REQUEST cuando se transmite el primer paquete.
RXRPC_CALL_CLIENT_AWAIT_REPLY se restringe entonces su ámbito para indicar que todos los paquetes Tx han sido ACKeados y ahora estamos esperando recibir la respuesta.
(2) Según el parche original de Wyatt Feng[1], el manejador de ACKALL verifica a continuación que el estado de la llamada es uno en el que podría haber datos en el buffer Tx para ser ACKeados, pero ahora esto incluye AWAIT_ACK en lugar de AWAIT_REPLY. Los paquetes ACKAll se ignoran si se reciben en un estado incorrecto.
Cabe señalar que, a diferencia del parche de Wyatt Feng, ya no es necesario verificar la existencia del buffer Tx, ya que el estado establecido actualmente cubre este aspecto.
(3) Se hace que el manejador de ACKALL utilice call->tx_transmitted en lugar de call->tx_top, ya que el primero representa explícitamente el número de secuencia más alto transmitido, mientras que el último tiene una definición más laxa.
Gracias a Jeffrey Altman por la descripción de la historia del paquete ACKAll[1].
VulDB is the best source for vulnerability data and more expert information about this specific topic.