From: Frédéric Lécaille <flecaille@haproxy.com>
Date: Mon, 10 Jan 2022 17:31:07 +0000 (+0100)
Subject: MINOR: quic: Wrong CRYPTO frame concatenation
X-Git-Tag: v2.6-dev1~147
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=81cd3c8eedf315b072828267e173adc4ebb1f6d5;p=thirdparty%2Fhaproxy.git

MINOR: quic: Wrong CRYPTO frame concatenation

This commit was not correct:
	 "MINOR: quic: Only one CRYPTO frame by encryption level"
Indeed, when receiving CRYPTO data from TLS stack for a packet number space,
there are rare cases where there is already other frames than CRYPTO data frames
in the packet number space, especially for 01RTT packet number space.  This is
very often with quant as client.
---

diff --git a/src/xprt_quic.c b/src/xprt_quic.c
index 92de7fad42..e21f3e4c59 100644
--- a/src/xprt_quic.c
+++ b/src/xprt_quic.c
@@ -993,8 +993,26 @@ static int quic_crypto_data_cpy(struct quic_enc_level *qel,
 	 */
 	if (!len) {
 		struct quic_frame *frm;
+		struct quic_frame *found = NULL;
+		struct mt_list *tmp1, tmp2;
 
-		if (MT_LIST_ISEMPTY(&qel->pktns->tx.frms)) {
+		/* There is at most one CRYPTO frame in this packet number
+		 * space. Let's look for it.
+		 */
+		mt_list_for_each_entry_safe(frm, &qel->pktns->tx.frms,
+		                            mt_list, tmp1, tmp2) {
+			if (frm->type != QUIC_FT_CRYPTO)
+				continue;
+
+			/* Found */
+			found = frm;
+			break;
+		}
+
+		if (found) {
+			found->crypto.len += cf_len;
+		}
+		else {
 			frm = pool_alloc(pool_head_quic_frame);
 			if (!frm)
 				return 0;
@@ -1005,10 +1023,6 @@ static int quic_crypto_data_cpy(struct quic_enc_level *qel,
 			frm->crypto.qel = qel;
 			MT_LIST_APPEND(&qel->pktns->tx.frms, &frm->mt_list);
 		}
-		else {
-			frm = MT_LIST_NEXT(&qel->pktns->tx.frms, struct quic_frame *, mt_list);
-			frm->crypto.len += cf_len;
-		}
 	}
 
 	return len == 0;