CVE-2026-74586

Resumen

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: sctp: limpiar new_transport al eliminar un par sctp_process_asconf_param() almacena un transporte de par recién añadido en asoc -> new_transport. Después de que todos los parámetros en el fragmento ASCONF han sido procesados, sctp_sf_do_asconf() usa este puntero para enviar un HEARTBEAT al nuevo transporte. Un ASCONF autenticado de un par SCTP remoto puede añadir un transporte y eliminarlo de nuevo con un parámetro DEL-IP comodín en el mismo fragmento. La eliminación comodín preserva el transporte en el que llegó el ASCONF, pero elimina el transporte recién añadido a través de sctp_assoc_del_nonprimary_peers(). La eliminación no limpia asoc -> new_transport, dejándolo apuntando al transporte eliminado. sctp_sf_do_asconf() entonces crea un HEARTBEAT cuyo chunk -> transport apunta al transporte eliminado sin mantener una referencia de transporte. Durante el reemplazo de dirección local, src_out_of_asoc_ok mantiene este HEARTBEAT en control_chunk_list. Después de que el transporte es liberado por RCU, un ASCONF_ACK exitoso para la dirección de reemplazo libera el HEARTBEAT en cola y sctp_outq_select_transport() lee el estado del transporte liberado. El problema fue encontrado durante una auditoría estática de objetos SCTP. Con un par autenticado, el reproductor activó el mismo informe KASAN en 2 de 2 ejecuciones sin parchear en un kernel netdev/main habilitado para KASAN: BUG: KASAN: uso después de liberación de slab en sctp_outq_select_transport Lectura de tamaño 4 en la dirección ffff88800b9bd95c por la tarea python3/197 Traza de Llamada: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Asignado por la tarea 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Última creación de trabajo potencialmente relacionada: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] El primer acceso inválido fue una lectura de cuatro bytes de transport -> state en net/sctp/outqueue.c:833. El mismo reproductor completó la secuencia completa de ASCONF autenticado y reemplazo de dirección local con este cambio sin un informe KASAN o oops. Limpiar new_transport cuando su par es eliminado, antes de que pueda ser usado para crear el HEARTBEAT.

Fuentes