]> git.ipfire.org Git - thirdparty/haproxy.git/commit
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>
Thu, 2 Jan 2025 08:58:23 +0000 (09:58 +0100)
commit22f8d2c99e71599f12f03829f3c62150b1289389
tree5cda5cc204df798a0d0b8d8268810159cf9afa15
parent98064537423fafe05b9ddd97e81cedec8b6b278d
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.
src/mux_h2.c