MINOR: mux-quic: Don't send an emtpy H3 DATA frame during zero-copy forwarding
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 4 Jun 2024 17:01:18 +0000 (19:01 +0200)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Thu, 5 Dec 2024 16:07:37 +0000 (17:07 +0100)
It may only happens when there is no data to forward but a last stream frame
must be sent with the FIN bit. It is not invalid, but it is useless to send
an empty H3 DATA frame in that case.

(cherry picked from commit 6697e87ae5e1f569dc87cf690b5ecfc049c4aab0)
[ad: This patch was merely considered as an optimization. However, it
 is in fact mandatory as it fixes a bug on QUIC zero-copy
 implementation. As such, it must be backported up to 2.9.

This bug can happen when iobuf data is null in done_ff, indicating that
no data were transferred. Despite this, qcc_send_stream() was always
called with data incorrectly incremented to iobuf offset, which is equal
to HTTP/3 frame header length. This could cause garbage data emission by
QUIC MUX. The most visible effect is that it provokes a BUG_ON() crash
when QCS instance is released due to Tx offsets desynchronization.

This bug is related to github issue #2678.]

Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>

src/mux_quic.c

index d7ad45d..565b144 100644 (file)
@@ -3148,7 +3148,8 @@ static size_t qmux_strm_done_ff(struct stconn *sc)
                goto end;
        }
 
-       data += sd->iobuf.offset;
+       if (data)
+               data += sd->iobuf.offset;
        total = qcs->qcc->app_ops->done_ff(qcs);
 
        if (data || qcs->flags & QC_SF_FIN_STREAM)