CVE-2026-74588

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: keep chunk-&gt;transport in step with the list it is queued on<br /> <br /> __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport&amp;#39;s<br /> transmitted list without updating chunk-&gt;transport:<br /> <br /> if (chunk-&gt;tsn_gap_acked) {<br /> list_move_tail(&amp;chunk-&gt;transmitted_list,<br /> &amp;transport-&gt;transmitted);<br /> continue;<br /> }<br /> <br /> The chunk then sits on a live transport&amp;#39;s list while chunk-&gt;transport still<br /> names a different one. If that transport is removed - sctp_assoc_rm_peer()<br /> from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk<br /> is left with a dangling pointer. sctp_assoc_rm_peer() scrubs<br /> peer-&gt;transmitted and asoc-&gt;outqueue.out_chunk_list, but the chunk is on<br /> neither.<br /> <br /> The pointer is not followed while tsn_gap_acked is set. A SACK that<br /> reneges on the TSN clears the flag, and the next SACK reaches<br /> <br /> tchunk-&gt;transport-&gt;flight_size -= sctp_data_size(tchunk);<br /> <br /> inside the freed transport. KASAN reports a slab-use-after-free read in<br /> sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the<br /> removal and the SACKs come from the association peer.<br /> <br /> Set chunk-&gt;transport at the move. The ordinary resend path needs nothing:<br /> it reaches its list_move_tail() only after sctp_packet_append_chunk()<br /> returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the<br /> chunk by then.<br /> <br /> Discovered by XBOW, triaged by Baul Lee