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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrigen múltiples encapsulamientos de sk->sk_rmem_alloc. __udp_enqueue_schedule_skb() tiene la siguiente condición: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf se inicializa con net.core.rmem_default y posteriormente se puede configurar con SO_RCVBUF, que está limitado por net.core.rmem_max o SO_RCVBUFFORCE. Si se establece INT_MAX en sk->sk_rcvbuf, la condición siempre es falsa, ya que sk->sk_rmem_alloc también es un entero con signo. En ese caso, el tamaño del skb entrante se añade a sk->sk_rmem_alloc incondicionalmente. Esto provoca un desbordamiento de enteros (posiblemente varias veces) en sk->sk_rmem_alloc y permite que un único socket tenga skb hasta net.core.udp_mem[1]. Por ejemplo, si establecemos un valor grande en udp_mem[1] e INT_MAX en sk->sk_rcvbuf e inundamos el socket con paquetes, podemos ver múltiples desbordamientos: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- invirtiendo el signo repetidamente skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Anteriormente, teníamos una verificación de límite para INT_MAX, que se eliminó mediante el commit 6a1f12dd85a8 ("udp: relajar la operación atómica en sk->sk_rmem_alloc"). Una solución completa sería revertirlo y limitar el operando derecho con INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; pero no queremos añadir el costoso atomic_add_return() solo para casos excepcionales. Convertir rmem a unsigned int evita múltiples encapsulamientos, pero aún permite un único encapsulamiento. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) Por lo tanto, definamos rmem y rcvbuf como unsigned int y verifiquemos skb->truesize solo cuando rcvbuf sea lo suficientemente grande como para reducir la posibilidad de desbordamiento. Tenga en cuenta que aún existe una pequeña probabilidad de ver un desbordamiento si se procesan múltiples skbs al mismo socket en diferentes núcleos al mismo tiempo y cada tamaño no excede el límite, pero el tamaño total sí. Tenga en cuenta también que debemos ignorar skb->truesize para un buffer pequeño como se explica en el commit 363dc73acacb ("udp: sea menos conservador con la contabilidad de sock rmem").