Vulnerabilidad en kernel de Linux (CVE-2025-21710)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: gestión correcta de la compresión extrema de memoria Las pruebas con iperf3 utilizando el empalmador de protocolo "pasta" han revelado un problema en la forma en que tcp gestiona la publicidad de ventanas en situaciones de compresión extrema de memoria. Bajo presión de memoria, un endpoint de socket puede anunciar temporalmente una ventana de tamaño cero, pero esto no se almacena como parte de los datos del socket. El razonamiento detrás de esto es que se considera una configuración temporal que no debería influir en ningún cálculo posterior. Sin embargo, si nos quedamos en un valor desafortunado del tamaño de ventana actual, el algoritmo que selecciona un nuevo valor fallará constantemente en anunciar una ventana distinta de cero una vez que hayamos liberado suficiente memoria. Esto significa que la noción de este lado del tamaño de ventana actual es diferente de la última anunciada al par, lo que hace que este último no envíe ningún dato para resolver la situación. El problema ocurre en el lado del servidor iperf3, y el socket en cuestión es un socket completamente normal con la configuración predeterminada para el kernel fedora40. No utilizamos SO_PEEK o SO_RCVBUF en el socket. El siguiente extracto de una sesión de registro, con comentarios propios agregados, muestra con más detalle lo que está sucediendo: // tcp_v4_rcv(->) // tcp_rcv_established(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ==== [5201<->39222]: tcp_data_queue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcp_data_queue(<-) [5201<->39222]: __tcp_transmit_skb(->) [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: tcp_select_window(->) [5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0 [5201<->39222]: tcp_select_window(<-) [5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160 [5201<->39222]: [__tcp_transmit_skb(<-) [5201<->39222]: tcp_rcv_established(<-) [5201<->39222]: tcp_v4_rcv(<-) // La cola de recepción está en 85 búferes y nos hemos quedado sin memoria. // Descartamos el búfer entrante, aunque esté en secuencia, y decidimos // enviar un anuncio con una ventana de cero. // No actualizamos tp->rcv_wnd y tp->rcv_wup en consecuencia, lo que significa // que reducimos incondicionalmente la ventana. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // Después de cada lectura, el algoritmo para calcular la nueva ventana de recepción // en __tcp_cleanup_rbuf() encuentra que es demasiado pequeña para anunciar // o actualizar tp->rcv_wnd. // Mientras tanto, el par piensa que la ventana es cero y no enviará // más datos para activar una actualización desde el lado del modo de interrupción. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n ---truncada---