Ubuntu unattended-upgrades 推送的 HAProxy 更新引发严重回归

发布版本：Ubuntu 22.04 LTS（jammy） 软件包：haproxy 2.4.30-0ubuntu0.22.04.3（jammy-security，USN-8972-1） 上一版本：2.4.30-0ubuntu0.22.04.2（工作正常） [影响] 从 .2 升级到 .3 之后，经过 HAProxy 的请求中有很大一部分（大约 50-70%）开始以 HTTP 502 失败。所有发送 chunked 响应的 HTTP/1.1 后端都受影响（在我们的案例中是 Apache/PHP、Node.js 和一个 git smart-HTTP 服务器）。后端本身没有变动，且状态正常。降级回 2.4.30-0ubuntu0.22.04.2 后问题立即消失。 [症状]

• HAProxy 日志：状态 502，终止状态为“PHNN”（处理服务器响应时代理中止），Tr = -1，出现在所有受影响的后端上。
• “show errors”（通过 master CLI）将每个事件显示为“invalid response”，并带有： H1 msg state MSG_CHUNK_SIZE(26) H1 chunk len 0 bytes, H1 body len <完整 body 大小> bytes len 0, error at position 0 也就是说，整个 body 已经接收完毕，错误发生在等待下一个 chunk-size 行（通常是最后的“0”块）时。
• 间歇性出现：取决于下一个 chunk-size 行是否与前一 chunk 数据在同一次读取中到达。 [分析（来自阅读源码；未在测试环境中复现）] debian/patches/CVE-2026-110354.patch 在 src/h1_htx.c 的 h1_parse_msg_data() 中加入了： if (!ret && !ofs && !buf_room_for_htx_data(srcbuf)) { (*dsthtx)->flags |= HTX_FL_PARSING_ERROR; ... 其目的是检测“chunk-size 行超过一个完整缓冲区”的情况。但在 2.4 中，mux-h1 会在所有已接收数据解析完毕后释放输入缓冲区（src/mux_h1.c，h1_process_input()：“if (!b_data(&h1c->ibuf)) h1_release_buf(h1c, &h1c->ibuf);”）。已释放的缓冲区大小为 0，因此 buf_room_for_htx_data() 返回 0（b_room() == 0）。 当 chunked 响应被解析到某个 chunk 数据的末尾，而下一个 chunk-size 行尚未到达时，解析器处于 H1_MSG_CHUNK_SIZE 状态，且输入缓冲区为空（已释放）。在下一轮处理中，h1_parse_chunk_size() 返回 0（不完整，这是正确的），ofs 为 0，而 buf_room_for_htx_data() 为 0。因此新检查把缺失的缓冲区当作已满缓冲区，报告解析错误，于是一个有效的响应变成了 502。 上游提交信息指出“在 2.8 和 2.6 上不会出现循环”，这表明较旧的分支不会像 3.x 那样受到原始问题的影响，并且 backport 需要针对分支做适配。（未检查：noble 的 2.8.30-0ubuntu0.24.04.2 是否表现相同。） [建议的修复] 只有在确实存在完整缓冲区时，才将该行视为过长，例如在报告错误之前要求源缓冲区非空且已分配（b_size(srcbuf) != 0 且 b_data(srcbuf) != 0，或 b_full()）。或者，如果原始循环在 2.4 上不可能发生，就放弃在 2.4 上的 backport。 [临时解决方案] 降级到 2.4.30-0ubuntu0.22.04.2 并保持该版本： apt install --allow-downgrades haproxy=2.4.30-0ubuntu0.22.04.2 apt-mark hold haproxy [回归风险] 对于任何位于使用 chunked transfer-encoding 的 HTTP/1.1 服务器之前的 jammy HAProxy 来说，风险很高，而这种情况非常常见。