Public bug reported:
Release: Ubuntu 22.04 LTS (jammy)
Package: haproxy 2.4.30-0ubuntu0.22.04.3 (jammy-security, USN-8972-1)
Previous version: 2.4.30-0ubuntu0.22.04.2 (works)
[Impact]
After upgrading from .2 to .3, a large share (roughly 50-70%) of requests
through HAProxy started failing with HTTP 502. It affected every HTTP/1.1
backend that sends chunked responses (Apache/PHP, Node.js, and a git smart-HTTP
server in our case). The backends themselves were unchanged and healthy.
Downgrading to 2.4.30-0ubuntu0.22.04.2 fixed it immediately.
[Symptoms]
- HAProxy log: status 502 with termination state "PHNN" (proxy aborted while
processing the server response), Tr = -1, on all affected backends.
- "show errors" (via the master CLI) shows every event as "invalid response"
with:
H1 msg state MSG_CHUNK_SIZE(26)
H1 chunk len 0 bytes, H1 body len <full body size> bytes
len 0, error at position 0
i.e. the whole body had already been received, and the error happens while
waiting for the next chunk-size line (typically the final "0" chunk).
- Intermittent: it depends on whether the next chunk-size line arrives in the
same read as the preceding chunk data.
[Analysis (from reading the source; not reproduced in a test harness)]
debian/patches/CVE-2026-110354.patch adds to h1_parse_msg_data() in
src/h1_htx.c:
if (!ret && !ofs && !buf_room_for_htx_data(srcbuf)) {
(*dsthtx)->flags |= HTX_FL_PARSING_ERROR;
...
}
This is meant to detect "chunk-size line longer than a full buffer". But in
2.4, mux-h1 releases the input buffer once all received data has been parsed
(src/mux_h1.c, h1_process_input(): "if (!b_data(&h1c->ibuf))
h1_release_buf(h1c, &h1c->ibuf);"). A released buffer has size 0, so
buf_room_for_htx_data() returns 0 (b_room() == 0).
When a chunked response is parsed up to the end of a chunk's data and the next
chunk-size line has not arrived yet, the parser is in H1_MSG_CHUNK_SIZE with an
empty (released) input buffer. On the next pass, h1_parse_chunk_size() returns 0
(incomplete, correct), ofs is 0, and buf_room_for_htx_data() is 0. The new check
therefore treats the missing buffer as a FULL buffer and reports a parsing
error, so a valid response becomes a 502.
The upstream commit message notes that "no loop can be experienced on 2.8 and
2.6", which suggests older branches were not affected by the original issue
the way 3.x is, and that the backport needs branch-specific adaptation. (Not
checked: whether noble's 2.8.30-0ubuntu0.24.04.2 behaves the same way.)
[Suggested fix]
Only treat the line as too long when there really is a full buffer, e.g.
require a non-empty, allocated source buffer (b_size(srcbuf) != 0 and
b_data(srcbuf) != 0, or b_full()) before reporting the error. Alternatively,
drop the backport on 2.4 if the original loop cannot occur there.
[Workaround]
Downgrade to 2.4.30-0ubuntu0.22.04.2 and hold it:
apt install --allow-downgrades haproxy=2.4.30-0ubuntu0.22.04.2
apt-mark hold haproxy
[Regression potential]
High for any jammy HAProxy fronting HTTP/1.1 servers that use chunked
transfer-encoding, which is very common.
** Affects: haproxy (Ubuntu)
Importance: Undecided
Status: New
** Tags: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172897
Title:
haproxy 2.4.30-0ubuntu0.22.04.3: CVE-2026-110354 backport causes
intermittent 502 (PH) on valid chunked responses
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/2172897/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
