Handle app data records from the next epoch

It is possible that DTLS records are received out of order such that
records from the next epoch arrive before we have finished processing the
current epoch. We are supposed to buffer such records but for some reason
we only did that for handshake and alert records. This is incorrect since
it is perfectly possible for app data records to arrive early too.

Fixes #20597

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20628)

diff --git a/ssl/record/methods/dtls_meth.c b/ssl/record/methods/dtls_meth.c
index 2dae86b44ccce58db154d906762a21eac654d59d..7b16f42c47a80f933304958fcf725d9e1be200df 100644 (file)
--- a/ssl/record/methods/dtls_meth.c
+++ b/ssl/record/methods/dtls_meth.c
@@ -90,13 +90,11 @@ static DTLS_BITMAP *dtls_get_bitmap(OSSL_RECORD_LAYER *rl, TLS_RL_RECORD *rr,
         return &rl->bitmap;
 
     /*
-     * Only HM and ALERT messages can be from the next epoch and only if we
-     * have already processed all of the unprocessed records from the last
-     * epoch
+     * We can only handle messages from the next epoch if we have already
+     * processed all of the unprocessed records from the previous epoch
      */
     else if (rr->epoch == (unsigned long)(rl->epoch + 1)
-             && rl->unprocessed_rcds.epoch != rl->epoch
-             && (rr->type == SSL3_RT_HANDSHAKE || rr->type == SSL3_RT_ALERT)) {
+             && rl->unprocessed_rcds.epoch != rl->epoch) {
         *is_next_epoch = 1;
         return &rl->next_bitmap;
     }