AZL-97232

In the Linux kernel, the following vulnerability has been resolved:

sctp: keep chunk->transport in step with the list it is queued on

_sctpoutqflushrtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport:

if (chunk->tsn_gap_acked) {
    list_move_tail(&chunk->transmitted_list,
               &transport->transmitted);
    continue;
}

The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. sctpassocrmpeer() scrubs peer->transmitted and asoc->outqueue.outchunklist, but the chunk is on neither.

The pointer is not followed while tsngapacked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches

tchunk->transport->flight_size -= sctp_data_size(tchunk);

inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrm_peer(). Both the removal and the SACKs come from the association peer.

Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its listmovetail() only after sctppacketappendchunk() returned SCTPXMIT_OK, and _sctppacketappendchunk() has rebound the chunk by then.

Discovered by XBOW, triaged by Baul Lee baul.lee@xbow.com