BUG/MEDIUM: quic: CRYPTO frame freeing without eb_delete()
authorFrederic Lecaille <flecaille@haproxy.com>
Mon, 1 Sep 2025 08:39:00 +0000 (10:39 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Wed, 1 Oct 2025 14:48:34 +0000 (16:48 +0200)
commitd62c2145b20793e129b80d63f5e973d59efd5391
treee1cf4a7a3af6cfb6aa1c698a7078e53b262193d4
parentdef8bd55e8b568a1377a8a294372ad00e64fb178
BUG/MEDIUM: quic: CRYPTO frame freeing without eb_delete()

Since this commit:

BUG/MINOR: quic: reorder fragmented RX CRYPTO frames by their offsets

when they are parsed, the CRYPTO frames are ordered by their offsets into an ebtree.
Then their data are provided to the ncbufs.

But in case of error, when qc_handle_crypto_frm() returns QUIC_RX_RET_FRM_FATAL
or QUIC_RX_RET_FRM_AGAIN), they remain attached to their tree. Then
from <err> label, they are deteleted and deleted (with a while(node) { eb_delete();
qc_frm_free();} loop). But before this loop, these statements directly
free the frame without deleting it from its tree, if this is a CRYPTO frame,
leading to a use after free when running the loop:

     if (frm)
    qc_frm_free(qc, &frm);

This issue was detected by the interop tests, with quic-go as client. Weirdly, this
client sends CRYPTO frames by packet with holes.
Must be backported as far as 2.6 as the commit mentioned above.

(cherry picked from commit 800ba73a9ca39dc0e0c33230c87ececd540f5541)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit ed1b2dc1f8ec5a68dbf3e075d4bffd5bc738bf2b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit e3b7cd5d61b6ea1c1b42ddcd5539e1fdf9cfe542)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/quic_rx.c