BUG/MAJOR: mux-h2: don't try to decode a response HEADERS frame in idle state
authorWilly Tarreau <w@1wt.eu>
Sun, 24 Nov 2019 13:57:53 +0000 (14:57 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 25 Nov 2019 10:34:20 +0000 (11:34 +0100)
commit57a1816faec652d9c7fbd9be48ce25c832be20d9
tree0059581ff494740f8e361c10b496c5190602e6f2
parent146f53ae7e97dbfe496d0445c2802dd0a30b0878
BUG/MAJOR: mux-h2: don't try to decode a response HEADERS frame in idle state

Christopher found another issue in the H2 backend implementation that
results from a miss in the H2 spec: the processing of a HEADERS frame
is always permitted in IDLE state, but this doesn't make sense on the
response path! And here when facing such a frame, we try to decode it
while we didn't allocate any stream, so we end up trying to fill the
idle stream's buffer (read-only) and crash.

What we're doing here is that if we get a HEADERS frame in IDLE state
from a server, we terminate the connection with a PROTOCOL_ERROR. No
such transition seems to be permitted by the spec but it seems to be
the only sane solution.

This fix must be backported as far as 1.9. Note that in 2.0 and earlier
there's no h2_frame_check_vs_state() function, instead the check is
inlined in h2_process_demux().
src/mux_h2.c