Verification result for the maintainer's proposed
2.4.30-0ubuntu0.22.04.4 from comment #13: PASS in the tested scope.
Qualification completed on 2026-11-05 at 03:27 UTC, using disposable
Ubuntu 22.04 amd64 containers. At the 03:22 UTC PPA check, the amd64
build still reported "Uploading build" and the signed package index
contained no .4 binary. I therefore rebuilt the authenticated PPA source
locally as 2.4.30-0ubuntu0.22.04.4+localverify1. Both InRelease
signatures and the signed-index/source SHA256 chain were verified. The
local version/changelog entry was the only local change; no HAProxy
source code was modified locally. This is qualification of the
maintainer's source via an unsigned local rebuild.
Fresh comparison results:
Version Complete valid bodies Protocol/security
controls Original reproducer Backend GETs
Official .2 240/240 10/28
10/10 30/30
Official .3 60/240 26/28
0/10 1/30
Maintainer .4, local rebuild 240/240 28/28
10/10 30/30
The 240 valid-response checks cover 12 fixtures, ten repetitions each at
one and two threads: fragmented final chunks, coalesced messages,
delayed chunks after coalesced headers/data, split chunk-size
lines/CRLF, trailers, extensions, empty bodies, a 64 KiB stream,
Content-Length, and close-delimited responses. A pass requires HTTP 200
with a complete, exact matching body.
The 28 protocol/security controls cover fragmented uploads, prompt
rejection of oversized request/response chunk-size and extension lines
at 1024/16384-byte buffer sizes, recovery afterward, and HTTP/2-preface
handling on first versus subsequent requests. These checks passed for
.4, with the other .3 security patches retained.
The .4 rebuild also passed 30 read-only GETs through temporary loopback
proxy listeners to three real ingress nodes: the expected root redirect
and complete login response. The .3 comparison still reproduced the
failures. Backend TLS used SNI with certificate verification disabled
for this isolated canary connection.
The added coalesced-header/body fixtures were motivated by the truncated
HTTP 200 reports. Under these timings, .3 returned 502; I did not
independently reproduce the truncated-200 variant. The .4 rebuild
returned complete matching bodies throughout.
Source/package audit passed: the only HAProxy code change from .3 is the
b_data(srcbuf) guard in src/h1_htx.c. The upstream tarball, patch
series, other security patches, mux_h1.c, packaged configuration/service
files, and compiled feature flags match .3. The tested executable
matches the locally built package.
Local package SHA256:
f45748f3fabbbf8bdc8a9d3035951ff79eff8c19effe04bc37aec0a455b41ff1
Tested executable SHA256:
5ec86f3587f9663071409338ecb599f1ff0231dd9dcd7753ca41b3e8c5a9f9ab
Production readbacks before and after testing confirmed active, held .2,
unchanged configuration, and six successful public checks on each
readback. No production package, service, routing, configuration, or
hold was changed. Full interactive workflows, load/soak behavior, and
the official PPA binary were not tested.
The maintainer's proposed source resolves our reproduced chunked-
response 502 regression while passing the exercised parser/security
controls. Thank you for preparing the fix.
--
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
