]> git.kaiwu.me - haproxy.git/commit
BUG/MINOR: h1: don't use uninitialized start line pointers when restarting
authorChristopher Faulet <cfaulet@haproxy.com>
Wed, 7 Oct 2026 08:57:06 +0000 (10:57 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Fri, 16 Oct 2026 17:10:26 +0000 (19:10 +0200)
commit893a72800ab67bf0349f460594822d55b6e8a4d1
treee3185fe3d03fc042114f99c6bc878ea0f8128c95
parent1da4ce0e7b34fed9c4f94fd5f33f6095f86db5d2
BUG/MINOR: h1: don't use uninitialized start line pointers when restarting

When h1_headers_to_hdr_list() is called again on an incomplete message,
it resumes from the state where it stopped, scans until the end of the
headers, then restarts the parsing from the beginning. During this first
scan, the start line elements (union h1_sl) were not set by the current
call and are uninitialized. However two places in the response start
line parsing still use them:

  - in H1_MSG_RPVER, sl.st.v.ptr is used to compute the version length
    and to read the version's digits to set H1_MF_VER_11. The result is
    discarded on restart, but this reads from a random pointer if the
    computed length is 8;

  - in H1_MSG_RPCODE, the number of digits is computed from sl.st.c.ptr
    since commit 8bdcc5516 ("BUG/MEDIUM: h1: limit status codes to 3
    digits by default"). With a random pointer, a valid response whose
    status code is split across two reads (e.g. "HTTP/1.1 2" then
    "00 OK...") may be rejected as invalid in strict mode, or its error
    position captured in lenient mode, depending on the stack contents.

Now the start line pointers are initialized to the beginning of the
message, and these checks are skipped during the first scan of a
restart, since they are performed again during the full parsing.

This only concerns responses, so it can only be triggered by a server.
It must be backported wherever commit 8bdcc5516 was backported. The RPVER
part may be backported further but it is harmless.
src/h1.c