CVE-2026-74586

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear new_transport when removing a peer<br /> <br /> sctp_process_asconf_param() stores a newly added peer transport in<br /> asoc-&gt;new_transport. After all parameters in the ASCONF chunk have been<br /> processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the<br /> new transport.<br /> <br /> An authenticated ASCONF from a remote SCTP peer can add a transport and<br /> remove it again with a wildcard DEL-IP parameter in the same chunk. The<br /> wildcard deletion preserves the transport on which the ASCONF arrived, but<br /> removes the newly added transport through<br /> sctp_assoc_del_nonprimary_peers(). The removal does not clear<br /> asoc-&gt;new_transport, leaving it pointing to the removed transport.<br /> <br /> sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk-&gt;transport points<br /> to the removed transport without holding a transport reference. During<br /> local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on<br /> control_chunk_list. After the transport is freed by RCU, a successful<br /> ASCONF_ACK for the replacement address releases the queued HEARTBEAT and<br /> sctp_outq_select_transport() reads the freed transport&amp;#39;s state.<br /> <br /> The issue was found during a static audit of SCTP objects. With an<br /> authenticated peer, the reproducer triggered the same KASAN report in 2<br /> of 2 unpatched runs on a KASAN-enabled netdev/main kernel:<br /> <br /> BUG: KASAN: slab-use-after-free in sctp_outq_select_transport<br /> Read of size 4 at addr ffff88800b9bd95c by task python3/197<br /> <br /> Call Trace:<br /> sctp_outq_select_transport+0x549/0x8b0 [sctp]<br /> sctp_outq_flush+0x306/0x2c60 [sctp]<br /> sctp_transport_immediate_rtx+0xaf/0x260 [sctp]<br /> sctp_process_asconf_ack+0xa48/0xf70 [sctp]<br /> <br /> Allocated by task 197:<br /> sctp_transport_new+0x68/0x650 [sctp]<br /> sctp_assoc_add_peer+0x258/0x12a0 [sctp]<br /> sctp_process_asconf+0x5e9/0x1090 [sctp]<br /> <br /> Last potentially related work creation:<br /> __call_rcu_common.constprop.0+0x77/0xb70<br /> sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp]<br /> sctp_process_asconf+0xd9c/0x1090 [sctp]<br /> <br /> The first invalid access was a four-byte read of transport-&gt;state at<br /> net/sctp/outqueue.c:833. The same reproducer completed the full<br /> authenticated ASCONF and local-address replacement sequence with this<br /> change without a KASAN report or oops.<br /> <br /> Clear new_transport when its peer is removed, before it can be used to<br /> create the HEARTBEAT.