Suricata

Bug analysis :
In SSLv3ParseHandshakeType, we use the condition

if (ssl_state->curr_connp->message_start + ssl_state->curr_connp->message_length <
            ssl_state->curr_connp->bytes_processed + input_len)

write_len = (ssl_state->curr_connp->message_start + ssl_state->curr_connp->message_length) -
            ssl_state->curr_connp->bytes_processed;

• ssl_state->curr_connp->message_length = 9
• ssl_state->curr_connp->bytes_processed = 10
  Leading to bad write_len = 0xFFFFFFFF

We seem to need the 5 packets of the reproducer to get this :

• ssl_state->curr_connp->message_length = 9
• ssl_state->curr_connp->bytes_processed = 9

Second packet is from client to server to progress handshake somehow

    if (ssl_state->flags & SSL_AL_FLAG_CHANGE_CIPHER_SPEC) {
                /* In TLSv1.3, ChangeCipherSpec is only used for middlebox
                   compability (rfc8446, appendix D.4). */
                if ((ssl_state->client_connp.version > TLS_VERSION_12) &&
                       ((ssl_state->flags & SSL_AL_FLAG_STATE_SERVER_HELLO) == 0)) {
                    /* do nothing */
                } else {
                    break;
                }
            }

• ssl_state->curr_connp->message_length = 9
• ssl_state->curr_connp->bytes_processed = 10

Fourth packet is from the client and modifies ssl_state->client_connp.version so as to ssl_state->client_connp.version > TLS_VERSION_12 becomes true

Fifth and last packet from server triggers the integer underflow

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24060 is a new variant found