CVE-2023-53296 in Linux
Resumen
por VulDB • 2026-06-05
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
sctp: verificar el número de flujo de envío después de wait_for_sndbuf
Este parche corrige un caso extremo en el que el recuento de flujos de salida (out stream count) de la asociación (asoc) puede cambiar después de wait_for_sndbuf.
Cuando el hilo principal del cliente inicia una conexión, si su recuento de flujos de salida se establece en N mientras que el recuento de flujos de entrada en el servidor se establece en N - 2, otro hilo en el cliente sigue enviando mensajes con el número de flujo N - 1 y espera a sndbuf antes de procesar INIT_ACK.
Sin embargo, después de procesar INIT_ACK, el recuento de flujos de salida en el cliente se reduce a N - 2, igualando el recuento de flujos de entrada en el servidor. El fallo (crash) ocurre cuando el hilo que esperaba a sndbuf se despierta y envía el mensaje en un flujo que no existe (N - 1); la traza de llamada es la siguiente:
KASAN: null-ptr-deref en el rango [0x0000000000000038-0x000000000000003f]
Call Trace: <TASK> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]
sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline]
sock_sendmsg+0xde/0x190 net/socket.c:745
La corrección consiste en añadir una comprobación improbable (unlikely check) del número de flujo de envío después de que el hilo se despierte de wait_for_sndbuf.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.