From: Matt Caswell <matt@openssl.org>
Date: Mon, 27 Mar 2023 14:59:41 +0000 (+0100)
Subject: Handle app data records from the next epoch
X-Git-Tag: openssl-3.2.0-alpha1~1044
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5c476976ab8ef057ddbd8f110249d7c796a7f1b1;p=thirdparty%2Fopenssl.git

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 2dae86b44cc..7b16f42c47a 100644
--- 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;
     }