From 81cd3c8eedf315b072828267e173adc4ebb1f6d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= <flecaille@haproxy.com>
Date: Mon, 10 Jan 2022 18:31:07 +0100
Subject: [PATCH] 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.
---
 src/xprt_quic.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/src/xprt_quic.c b/src/xprt_quic.c
index 92de7fad4..e21f3e4c5 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;