DEBIAN-CVE-2026-74588

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->tsngapacked) { listmovetail(&chunk->transmittedlist,        &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->flightsize -= sctpdatasize(tchunk);  inside the freed transport.  KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer().  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 SCTPXMITOK, and _sctppacketappendchunk() has rebound the chunk by then.  Discovered by XBOW, triaged by Baul Lee baul.lee@xbow.com