Version in base suite: 3.0.11-1+deb13u3 Base version: haproxy_3.0.11-1+deb13u3 Target version: haproxy_3.0.11-1+deb13u4 Base file: /srv/ftp-master.debian.org/ftp/pool/main/h/haproxy/haproxy_3.0.11-1+deb13u3.dsc Target file: /srv/ftp-master.debian.org/policy/pool/main/h/haproxy/haproxy_3.0.11-1+deb13u4.dsc changelog | 7 patches/0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch | 137 ++++++++++ patches/0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch | 51 +++ patches/series | 3 4 files changed, 198 insertions(+) dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpmqw5kd7a/haproxy_3.0.11-1+deb13u3.dsc: no acceptable signature found dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpmqw5kd7a/haproxy_3.0.11-1+deb13u4.dsc: no acceptable signature found diff -Nru haproxy-3.0.11/debian/changelog haproxy-3.0.11/debian/changelog --- haproxy-3.0.11/debian/changelog 2026-05-20 19:21:22.000000000 +0000 +++ haproxy-3.0.11/debian/changelog 2026-10-15 16:14:18.000000000 +0000 @@ -1,3 +1,10 @@ +haproxy (3.0.11-1+deb13u4) trixie-security; urgency=high + + * BUG/MAJOR: mux-h2: properly handle short reads on PING frames + * BUG/MAJOR: h1-htx: report an error on a too long chunk-size line + + -- Vincent Bernat Thu, 15 Oct 2026 18:14:18 +0200 + haproxy (3.0.11-1+deb13u3) trixie-security; urgency=high [ Salvatore Bonaccorso ] diff -Nru haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch --- haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch 1970-01-01 00:00:00.000000000 +0000 +++ haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch 2026-10-15 16:14:18.000000000 +0000 @@ -0,0 +1,137 @@ +From fd0864b83920851eeaaa0dd934bfebc82ba6ca27 Mon Sep 17 00:00:00 2001 +From: Christopher Faulet +Date: Fri, 9 Oct 2026 15:34:58 +0200 +Subject: [PATCH] BUG/MAJOR: h1-htx: report an error on a too long chunk-size + line + +When a chunked message starts with a chunk-size line longer than the input +buffer, the parser was looping forever: the line was never complete, no data +could be consumed, and the connection remained stuck until the client +timeout because the buffer was full and could not be extended. + +The full-buffer detection used for too large headers and trailers is now +also applied to the chunk-size line: if nothing was parsed and the input +buffer is full, the line cannot possibly fit and a parsing error is reported +instead of waiting for more data that will never fit. + +A workaround consists to reject chunk-encoded request: + + http-request reject if { req.hdr(transfer-encoding) -i chunked } + +This should be backported at least to 3.0. But possibly to all stable +versions with some modifications. However, no loop can be experienced on 2.8 +and 2.6. + +Many thanks to Adam Crawford for the report and the fix. + +(cherry picked from commit 6e495dbb2a4850578439cf795966c068c1bdffe3) +[cf: VTC slightly adapted for 3.0] +Signed-off-by: Christopher Faulet +--- + .../http-messaging/h1_big_chunk_size_line.vtc | 65 +++++++++++++++++++ + src/h1_htx.c | 17 ++++- + 2 files changed, 81 insertions(+), 1 deletion(-) + create mode 100644 reg-tests/http-messaging/h1_big_chunk_size_line.vtc + +diff --git a/reg-tests/http-messaging/h1_big_chunk_size_line.vtc b/reg-tests/http-messaging/h1_big_chunk_size_line.vtc +new file mode 100644 +index 000000000000..064489d3f4d5 +--- /dev/null ++++ b/reg-tests/http-messaging/h1_big_chunk_size_line.vtc +@@ -0,0 +1,65 @@ ++varnishtest "Test a chunk-size line which fills the whole buffer" ++ ++# A chunked request whose first chunk-size line is longer than the ++# buffer used to cause an endless parsing loop: the parser could not ++# progress on the incomplete line, the buffer was full so no more data ++# could be received, and the connection remained stuck until the client ++# timeout. Such a line is now reported as a parsing error. ++# ++# The first client below sends a request whose first chunk-size line, ++# including its final LF, is longer than tune.bufsize, so it cannot ++# possibly fit in any buffer. The proxy must reply with a 400 at once ++# instead of remaining stuck until the client timeout. The error is ++# checked in the log because the response may be lost when the proxy ++# closes the connection with the request not fully drained. ++# ++# The second client sends a valid request to check that the proxy ++# remains alive and behaves normally. ++ ++feature ignore_unknown_macro ++ ++syslog S -level info { ++ recv ++ expect ~ ".* li1 li1/s1 [0-9]*/[0-9]*/-1/-1/[0-9]* 400 .* PC-- .* \"POST /big HTTP/1.1\"" ++} -start ++ ++haproxy h1 -conf { ++ global ++ .if feature(THREAD) ++ thread-groups 1 ++ .endif ++ tune.bufsize 1024 ++ ++ defaults ++ mode http ++ timeout connect "${HAPROXY_TEST_TIMEOUT-5s}" ++ timeout client "${HAPROXY_TEST_TIMEOUT-5s}" ++ timeout server "${HAPROXY_TEST_TIMEOUT-5s}" ++ ++ listen li1 ++ bind "fd@${li1}" ++ option httplog ++ option dontlog-normal ++ log "${S_addr}:${S_port}" local0 info ++ server s1 "${h1_li2_addr}:${h1_li2_port}" ++ ++ listen li2 ++ bind "fd@${li2}" ++ http-request return status 200 ++} -start ++ ++# 42 + 984 + 2 = 1028 bytes: too long for a 1024-byte buffer ++client c1 -connect ${h1_li1_sock} { ++ txreq -req POST -url /big -hdr "Transfer-Encoding: chunked" -nolen ++ send_n 984 "0" ++ send "\r\n" ++} -run ++ ++# a valid request must still work ++client c2 -connect ${h1_li1_sock} { ++ txreq -url /ok ++ rxresp ++ expect resp.status == 200 ++} -run ++ ++syslog S -wait +diff --git a/src/h1_htx.c b/src/h1_htx.c +index 0deadcb27e96..04823644a531 100644 +--- a/src/h1_htx.c ++++ b/src/h1_htx.c +@@ -887,7 +887,22 @@ size_t h1_parse_msg_data(struct h1m *h1m, struct htx **dsthtx, + } + else if (h1m->flags & H1_MF_CHNK) { + /* te:chunked : parse chunks */ +- total += h1_parse_msg_chunks(h1m, dsthtx, srcbuf, ofs, max, htxbuf); ++ sz = h1_parse_msg_chunks(h1m, dsthtx, srcbuf, ofs, max, htxbuf); ++ ++ /* Incomplete chunk-size line. If the input buffer only ++ * contains it and is full, which is detected by it being full ++ * and the offset to be zero, it's an error because the line is ++ * too large to be handled by the parser. Report a parsing ++ * error rather than retrying forever on the same data. ++ */ ++ if (!sz && !ofs && h1m->state == H1_MSG_CHUNK_SIZE && ++ !buf_room_for_htx_data(srcbuf)) { ++ (*dsthtx)->flags |= HTX_FL_PARSING_ERROR; ++ h1m->err_state = h1m->state; ++ h1m->err_pos = ofs; ++ return 0; ++ } ++ total += sz; + } + else if (h1m->flags & H1_MF_XFER_LEN) { + /* XFER_LEN is set but not CLEN nor CHNK, it means there is no +-- +2.55.0 + diff -Nru haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch --- haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch 1970-01-01 00:00:00.000000000 +0000 +++ haproxy-3.0.11/debian/patches/0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch 2026-10-15 16:14:18.000000000 +0000 @@ -0,0 +1,51 @@ +From 560f1019e55838187435f120b562fd66ce880303 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Mon, 12 Oct 2026 14:38:34 +0200 +Subject: [PATCH] BUG/MAJOR: mux-h2: properly handle short reads on PING frames + +Handling of partially received H2 frames was fixed in 2.5 with commit +b5f7b52968 ("BUG/MEDIUM: mux-h2: Handle remaining read0 cases on partial +frames"), however it turns out that the PING one was apparently missed. +However by then it was not a problem, but became one when commit 633c41c62 +("MEDIUM: mux-h2: rework h2_restart_reading() to differentiate recv and +demux") was merged in 3.1 because now the mux's tasklet can properly wake +up as long as the job is not finished, which unfortunately doesn't play +well once combined with the fix above, because as long as the data are +not consumed, we continue to wake up, and we don't consume them until +the frame is complete, or the timeout http-request strikes. + +Let's simply implement the check for the short read in h2c_handle_ping() +to avoid the spurious wakeup. + +This needs to be backported to 3.2, maybe even 2.6 since the checks in +other functions didn't change since then. + +As a workaround, setting "timeout http-request" to a low value such as +1-5s mitigates the CPU consumption. + +(cherry picked from commit 7ddb55bc18744996782e9e2b50f16b9b985d766b) +Signed-off-by: Willy Tarreau +--- + src/mux_h2.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/src/mux_h2.c b/src/mux_h2.c +index 9c853f98a609..b01458768819 100644 +--- a/src/mux_h2.c ++++ b/src/mux_h2.c +@@ -2556,6 +2556,12 @@ static int h2c_ack_settings(struct h2c *h2c) + */ + static int h2c_handle_ping(struct h2c *h2c) + { ++ /* process full frame only */ ++ if (b_data(&h2c->dbuf) < h2c->dfl) { ++ h2c->flags |= H2_CF_DEM_SHORT_READ; ++ return 0; ++ } ++ + /* schedule a response */ + if (!(h2c->dff & H2_F_PING_ACK)) + h2c->st0 = H2_CS_FRAME_A; +-- +2.55.0 + diff -Nru haproxy-3.0.11/debian/patches/series haproxy-3.0.11/debian/patches/series --- haproxy-3.0.11/debian/patches/series 2026-05-20 19:21:22.000000000 +0000 +++ haproxy-3.0.11/debian/patches/series 2026-10-15 16:14:18.000000000 +0000 @@ -23,5 +23,8 @@ 0001-BUG-MEDIUM-h1-Skip-all-h2c-values-from-Upgrade-heade.patch +0001-BUG-MAJOR-mux-h2-properly-handle-short-reads-on-PING.patch +0001-BUG-MAJOR-h1-htx-report-an-error-on-a-too-long-chunk.patch + # applied during the build process: # debianize-dconv.patch