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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrige la fuga de contabilidad de memoria. Matt Dowling informó de un extraño problema de uso de memoria UDP. En condiciones normales de funcionamiento, el uso de memoria UDP informado en /proc/net/sockstat se mantiene cercano a cero. Sin embargo, ocasionalmente alcanzaba 524 288 páginas y nunca se reducía. Además, el valor se duplicaba al finalizar la aplicación. Finalmente, causaba pérdidas intermitentes de paquetes. Podemos reproducir el problema con el siguiente script [0]: 1. /proc/net/sockstat informa 0 páginas # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Ejecute el script hasta que el informe alcance 524 288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Matar el socket y confirmar que el número nunca baje # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necesario desde v6.0) Desencadenar proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. El número se duplica # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 La aplicación estableció INT_MAX en SO_RCVBUF, lo que desencadenó un desbordamiento de entero en udp_rmem_release(). Cuando se cierra un socket, udp_destruct_common() purga su cola de recepción y suma skb->truesize en ella. Este total se calcula y se almacena en una variable local de entero sin signo. El tamaño total se pasa a udp_rmem_release() para ajustar la memoria. Sin embargo, dado que la función acepta un argumento de entero con signo, el tamaño total puede volver a la normalidad, provocando un desbordamiento. La cantidad liberada se calcula de la siguiente manera: 1) Sumar size a sk->sk_forward_alloc. 2) Redondear sk->sk_forward_alloc al múltiplo inferior más cercano de PAGE_SIZE y asignarlo a amount. 3) Restar amount de sk->sk_forward_alloc. 4) Pasar amount >> PAGE_SHIFT a __sk_mem_reduce_allocated(). Cuando se produjo el problema, el total en udp_destruct_common() era 2147484480 (INT_MAX + 833), que se convirtió a -2147482816 en udp_rmem_release(). En 1) sk->sk_forward_alloc se cambia de 3264 a -2147479552, y 2) se establece -2147479552 en cantidad. 3) revierte el ajuste, por lo que no vemos ninguna advertencia en inet_sock_destruct(). Sin embargo, udp_memory_allocated se duplica en 4). Desde el commit 3cd3399dd7a8 ("net: implementar reservas por CPU para memory_allocated"), el uso de memoria ya no se duplica inmediatamente después de cerrar un socket, ya que __sk_mem_reduce_allocated() almacena en caché la cantidad en udp_memory_per_cpu_fw_alloc. Sin embargo, la siguiente vez que un socket UDP recibe un paquete, la resta se aplica, duplicando el uso de memoria UDP. Este problema provoca que la asignación de memoria posterior falle una vez que el valor de sk->sk_rmem_alloc del socket supere net.ipv4.udp_rmem_min, lo que provoca la pérdida de paquetes. Para evitar este problema, usemos unsigned int para el cálculo y llamemos a sk_forward_alloc_add() solo una vez para la delta pequeña. Tenga en cuenta que first_packet_length() también podría tener el mismo problema. [0]: desde la importación de socket * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) datos = b'a' * 100 mientras sea verdadero: c.send(datos)