BUG/MEDIUM: mux-h2: Count copied data when looping on RX bufs in h2_rcv_buf()
authorChristopher Faulet <cfaulet@haproxy.com>
Thu, 2 Jan 2025 08:39:06 +0000 (09:39 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Mon, 6 Jan 2025 10:32:10 +0000 (11:32 +0100)
commit5909764827626c5eea30198eb9e55740a4a0e995
tree2021ef90aa0176156cfbbbf6449bf7698bb320a6
parent535b984d3bea70defb7a81baba9bff683c7add59
BUG/MEDIUM: mux-h2: Count copied data when looping on RX bufs in h2_rcv_buf()

When data was copied from RX buffers to the channel buffer, more data than
expected could be moved because amount of data copied was never decremented
from the limit. This could lead to a stream dead lock when the compression
filter was inuse.

The issue was introduced by commit 4eb3ff1 ("MAJOR: mux-h2: make streams use
the connection's buffers") but revealed by 3816c38 ("MAJOR: mux-h2: permit a
stream to allocate as many buffers as desired").

Because a h2 stream can now have several RX buffers, in h2_rcv_buf(), we
loop on these buffers to fill the channel buffer. However, we must still
take care to respect the limit to not copy to much data. However, the
"count" variable was never decremented to reflect amount of data already
copied. So, it was possible to exceed the limit.

It was an issue when the compression filter was inuse because the channel
buffer could be fully filled, preventing the compression to be
performed. When this happened, the stream was infinitly blocked because the
compression filter was asking for some space but nothing was scheduled to be
forwarded.

This patch should fix the issue #2826. It must be backported to 3.1.

(cherry picked from commit 22f8d2c99e71599f12f03829f3c62150b1289389)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/mux_h2.c