CVE-2025-38463

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: Correcto signado en el cálculo del espacio restante de skb Syzkaller informó de un error [1] en el que sk->sk_forward_alloc puede desbordarse. Al enviar datos, si existe un skb al final de la cola de escritura, el kernel intentará añadir los nuevos datos a ese skb. Sin embargo, el código que comprueba el espacio disponible en el skb presenta un fallo: ''' copy = size_goal - skb->len ''' Los tipos de las variables implicadas son: ''' copy: ssize_t (s64 en sistemas de 64 bits) size_goal: int skb->len: unsigned int ''' Debido a las reglas de promoción de tipos de C, el signed size_goal se convierte en un unsigned int para que coincida con skb->len antes de la resta. El resultado es un unsigned int. Cuando este resultado entero sin signo se asigna a la variable de copia s64, se extiende a cero, conservando su valor no negativo. Por lo tanto, la copia siempre es >= 0. Supongamos que enviamos 2 GB de datos y que size_goal se ha ajustado a un valor menor que skb->len. La resta hará que la copia contenga un entero positivo muy grande. En la lógica subsiguiente, este valor alto se utiliza para actualizar sk->sk_forward_alloc, lo que puede provocar fácilmente un desbordamiento. El reproductor syzkaller utiliza TCP_REPAIR para crear esta condición de forma fiable. Sin embargo, esto también puede ocurrir en situaciones reales. La función tcp_bound_to_half_wnd() también puede reducir size_goal a un valor pequeño. Esto provocaría que la función tcp_wmem_schedule() posterior estableciera sk->sk_forward_alloc en un valor cercano a INT_MAX. Las solicitudes de asignación de memoria adicionales harían que sk_forward_alloc se repita y se vuelva negativo. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks. For the stable distribution (trixie), these problems have been fixed in version 6.12.41-1.