Change Details

A client SACKing the FIN bit may cause an off-by-one access, due to a long dormant bug in the tcp_sack_doack() acceptance check for incoming SACK blocks. It is likely that the new PRR mechanism, by reducing self-inflicted packet loss, significantly increased the probabiliy to elicit this misbehavior.

Some clients (iOS, macOS, dragonflyBSD) will SACK the FIN bit, if it is sent during loss recovery while loss may be still ongoing. One PR 254725 has been reported, where this may have come into play. In order to avoid any unexpected interactions due to SACKed FINs, make sure to send the FIN only, when all data is acknowledged in full by the client.

ASome client SACKing the FIN bit may cause ans (iOS, macOS, dragonflyBSD) will off-by-one accessSACK the FIN bit, due to a long dormant bug in the tcp_sack_doack() acceptanceif it is sent during loss check for incoming SACK blocksrecovery while loss may be still ongoing. It is likely that the new PRR mechanism,One PR 254725 has been reported, where this may by reducing self-inflihave come into play. In order to avoid any unexpected packet lossinteractions due to SACKed FINs, significantly increased the probabiliy to elicit this misbehaviormake sure to send the FIN only, when all data is acknowledged in full by the client.