tree 0059581ff494740f8e361c10b496c5190602e6f2
parent 146f53ae7e97dbfe496d0445c2802dd0a30b0878
author Willy Tarreau <w@1wt.eu> 1574603873 +0100
committer Willy Tarreau <w@1wt.eu> 1574678060 +0100
encoding latin1

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().