BUG/MINOR: quic: prevent crash on conn access after MUX init failure
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Mon, 17 Feb 2025 16:15:49 +0000 (17:15 +0100)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Tue, 18 Mar 2025 14:51:04 +0000 (15:51 +0100)
commit0e5e197f2a071490e0f8f61e76beb230cefed600
treed8ab4f3c78b0dfac0e1a7c9f90539b2056552023
parent479c4b24460b43049ebe04544fb7e37ac7d55bc3
BUG/MINOR: quic: prevent crash on conn access after MUX init failure

Initially, QUIC-MUX was responsible to reset quic_conn <conn> member to
NULL when MUX was released. This was performed via qcc_release().

However, qcc_release() is also used on qmux_init() failure. In this
case, connection must be freed via its session, so QCC <conn> member is
resetted to NULL prior to qcc_release(), which prevents quic_conn <conn>
member to also be resetted. As the connection is freed soon after,
quic_conn <conn> is a dangling pointer, which may cause crashes.

This bug should be very rare as first it implies that QUIC-MUX
initialization has failed (for example due to a memory alloc error).
Also, <conn> member is rarely used by quic_conn instance. In fact, the
only reproducible crash was done with QUIC traces activated, as in this
case connection is accessed via quic_conn under __trace_enabled()
function.

To fix this, detach connection from quic_conn via the XPRT layer instead
of the MUX. More precisely, this is performed via quic_close(). This
should ensure that it will always be conducted, either on normal
connection closure, but also after special conditions such as MUX init
failure.

This should be backported up to 2.6.

(cherry picked from commit 2cdc4695cb82fce46d67cef17300ec7cf978906e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 82e7d79e727b148afae59592931fd0191c5eb1c5)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
src/mux_quic.c
src/xprt_quic.c