BUG/MAJOR: mux-h2: Properly detect too large frames when decoding headers
authorChristopher Faulet <cfaulet@haproxy.com>
Wed, 21 Apr 2021 08:39:53 +0000 (10:39 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Thu, 29 Apr 2021 09:10:46 +0000 (11:10 +0200)
commit393d087228688f487cf433a49bae5bf1551bd556
tree3eab43e33290252901bf744de83cc34237fd7a13
parenta025fa96b8d520dd7470617e4bcb241ef8e5a112
BUG/MAJOR: mux-h2: Properly detect too large frames when decoding headers

In the function decoding payload of HEADERS frames, an internal error is
returned if the frame length is too large. it cannot exceed the buffer
size. The same is true when headers are splitted on several frames. The
payload of HEADERS and CONTINUATION frames are merged and the overall size
must not exceed the buffer size.

However, there is a bug when the current frame is big enough to only have
the space for a part of the header of the next frame. Because, in this case,
we wait for more data, to have the whole frame header. We don't properly
detect that the headers are too large to be stored in one buffer. In fact
the test to trigger this error is not accurate. When the buffer is full, the
error is reported if the frame length exceeds the amount of data in the
buffer. But in reality, an error must be reported when we are unable to
decode the current frame while the buffer is full. Because, in this case, we
know there is no way to change this state.

When the bug happens, the H2 connection is woken up in loop, consumming all
the CPU. But the traffic is not blocked for all that.

This patch must be backported as far as 2.0.

(cherry picked from commit 07f88d7582c80522b1e83b9bbc473d338e48fb85)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 6284ee62436866b8341aff3458c43e14e170a178)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit b727f30a0b4655a24104f07b80ebc0bcb43d748c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/mux_h2.c