]> git.kaiwu.me - haproxy.git/commit
BUG/MAJOR: mux_quic: fix leak on RESET_STREAM reception
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 23 Sep 2026 12:32:30 +0000 (14:32 +0200)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Thu, 24 Sep 2026 09:17:31 +0000 (11:17 +0200)
commitb7e0aa231aa7af214c97f9540f7bba8498898b11
tree5c9ee9fec68c527b6f86d7638de5014ab6a5b973
parent65591cd879fffc313aa35cb124ad4d3eee7281d6
BUG/MAJOR: mux_quic: fix leak on RESET_STREAM reception

On QUIC MUX, <nb_hreq> counter serves to account for the currently
active requests in progress. While this number is non null, the
connection is considered active and cannot be released. The counter is
decremented only when the QCS instance is finally freed. This guarantees
that no truncated request could happen.

An issue happened on RESET_STREAM frame reception as the first frame for
a new QCS instance. In this case, <nb_hreq> is incremented. No progress
will occur as the upper stream layer is not instantiated, and QCS
instance will remains half-closed, which prevents its liberation.

The first issue is that it causes a leak of QCS during the connection
lifetime. Worst, this may prevent the whole connection closure even if
idle timeout as fired : this is because qcc_is_dead() checks <nb_hreq>
first before regarding transport layer status. Note that this only
happens if QUIC MUX timeout is not yet activated, which is the case if
qcc_io_cb() has not yet been executed.

This patch fixes this situation by improving RESET_STREAM receive
handler. Now, an extra check is performed to detect if the frame has
been received before the upper stream layer init. If true, QCS instance
is closed locally and immediately scheduled for purge, which ensures
that <nb_hreq> counter will be decremented as expected.

This must be backported up to 2.8.
src/mux_quic.c