GitLab

Some client protocols that use an abort message to reset the state machine are vulnerable to a race condition where incoming messages that were already in flight when the abort message was sent are received after resetting, causing further aborts. This is harmless if the state machine is still in the start state when the messages are received, but it may cause problems if the state machine has moved out of the start state.

The problem can be avoided by using an abort counter:

• Each party keeps a counter for each other party they sync with
• The counter is part of the session state
• The counter is initialised to zero
• The counter is reset to zero if the other party is removed as a contact
• The counter is included in every outgoing message
• Incoming messages with counters lower than the local counter are ignored
• The counter is incremented after sending or receiving an abort message

If two parties concurrently abort the protocol they may ignore each other's abort messages, but this appears to be harmless: either both will increment their counters once, or both twice.

Client protocols that use abort messages without counters will need to be upgraded to accommodate counters. It may be possible to do this with a minor version upgrade.