Hi, HAProxy 3.2.7 was released on 2025/10/23. It added 48 new commits after version 3.2.6.
We've seen a number of issues accumulate in the maintenance branch, so it seems it was about time to produce a new release. I'll focus on the most important ones: - a missed initialization in QUIC could trigger a BUG_ON() hence provoke a crash in qc_rcv_buf(). - the way certain QUIC stacks recently started to send their crypto frames leaving a single byte hole between them was fundamentally incompatible with our storage model which requires at least 8 bytes holes. As such, some of them would experience random connection failures due to dropped frames. This required to rework that storage part (the "ncbuf" stuff) to support an alternate byte-addressed area that is compatible with this behavior that we initially considered as irrelevant and only likely used by attackers. This new work has been extensively tested in produciton where the issue was first reported, and given that there were some reports of recent Firefox versions triggering the issue, we considered that we should not wait to backport it. Thanks Annika for your wonderful help BTW! - as mentioned previously here, we've got a report of accidental breakage in 3.0 of the hash algorithms involved in consistent hashing, that prevents some users from migrating from pre-3.0 to 3.0+ by causing too heavy a cache redistribution. The problem is that fixing it will also cause some redistribution for those running on affected versions. The overall consensus was that those not noticing the issue will not be impacted by the fix and those impacted by it have not upgraded because of it, so better fix it in any case. In order to know if you're subject to this problem, look for "hash-type consistent" in your config, and if present, then check if there is a "hash-key" setting. If the first one is present without the second one or with "hash-key id", you may notice a drop in cache hit ratio during the upgrade. If the cache hit ratio is already small (e.g. small storage), it may be better to upgrade all LB nodes at once. If the cache hit ratio is very high (large storage), it might be better to first upgrade one LB node to pre-heat the caches with the redistributed objects, then upgrade the other ones. But based on what was observed since then, it should pass smoothly at most if not all places. - declaring thread groups with non-existing threads would cause some listeners to fail to accept pending connections, or even to crash when trying to dispatch incoming connections to the same group's threads. This was fixed by refining the groups to only work with existing threads. However, if a group ends up with no thread, now an error will be reported and the process will refuse to start (which is always better than starting and rejecting traffic like today). This only concerns those with manually configured "thread-groups" directives in their configs. - sending lots of short commands on the CLI (e.g. "add acl") very fast could trigger the spinning loop detection and abort the process. The loop detection has indeed lost accuracy during the 3.2 rework of the applets, and commands that only consume data without producing any were not properly diagnosed. - a memory leak that affects the CLI since the 3.2 rework was fixed. Every connection that sends a command and immediately quit with before the response would leak one buffer. It can happen when constantly adjusting some settings (e.g. script that frequently connects to change a server's weight). - a bug on the CLI can cause a crash on "show pools" followed by some filtering or sorting if the output shows less than 100 pools (most common builds due to pools merging). - we've got some reports of segfaults at boot with GCC 15 and tree vectorization being applied to unaligned data at -O3, only for certain very specific targets (westmere and nehalem only). An extra build option to calm down that optimization was added that got rid of the issue, and greeted us with the pleasant surprise of improving the -O3 request rate by about 5%. All optimizations are not always as effective as planned. - 1xx responses in HTTP/3 were not always properly encoded if they would appear in the same response packet as the final response, and they would generally cause a parsing error on the client, which will abort the connection; 1xx sent along the final response are really not common right now and mostly happen in testing, but some applications could trigger them more than others. - a slow memory leak of SSL captures has been noticed over the last two years on haproxy.org, making us believe that it was in the SSL lib, because the counters we placed around it showed more calls to the init() callback than the release() one. We were actually wrong and discovered that in TLS 1.3 there can be two consecutive Client Hello messages on a connection and that this caused the capture area to be allocated twice and only the last one was freed. At least it explained everything, and this was fixed (and confirms to no longer leak). - a ring that would fail to connect to one of its servers could remain stuck forever if unlucky and it happens at a precise ms within the 20 first seconds of boot (then every 49.7 days). - a bug in mt_list_delete() applied to an already deleted entry in the process of being re-added was detected in 3.3-dev where it would make a development branch constantly fail. The fact that it was never noticed before comforts us in the idea that the pattern doesn't exist in 3.2 or older. But we preferred to backport the fix in case it would become necessary in the future and we'd forget about it. In addition to this, the acme code was updated to match 3.3 (various fixes), there were a few extra QUIC and TLS fixes and cleanups, build fixes and a small fix on stick-tables usage counters that could be wrong in case of memory allocation failure. And that's roughly all. For the vast majority of users there's no emergency to update to this version. But it's also a good opportunity to include it in new deployments. I haven't checked precisely but I think that many of the issues above also concern 3.1 and 3.0 so it's likely that more releases will be emitted soon as time permits. Please find the usual URLs below : Site index : https://www.haproxy.org/ Documentation : https://docs.haproxy.org/ Wiki : https://github.com/haproxy/wiki/wiki Discourse : https://discourse.haproxy.org/ Slack channel : https://slack.haproxy.org/ Issue tracker : https://github.com/haproxy/haproxy/issues Q&A from devs : https://github.com/orgs/haproxy/discussions Sources : https://www.haproxy.org/download/3.2/src/ Git repository : https://git.haproxy.org/git/haproxy-3.2.git/ Git Web browsing : https://git.haproxy.org/?p=haproxy-3.2.git Changelog : https://www.haproxy.org/download/3.2/src/CHANGELOG Dataplane API : https://github.com/haproxytech/dataplaneapi/releases/latest Pending bugs : https://www.haproxy.org/l/pending-bugs Reviewed bugs : https://www.haproxy.org/l/reviewed-bugs Code reports : https://www.haproxy.org/l/code-reports Latest builds : https://www.haproxy.org/l/dev-packages Willy --- Complete changelog : Amaury Denoyelle (11): MINOR: quic: restore QUIC_HP_SAMPLE_LEN constant BUG/MINOR: quic: check applet_putchk() for 'show quic' first line BUG/MEDIUM: h3: properly encode response after interim one in same buf MINOR: ncbuf: extract common types MINOR: ncbmbuf: define new ncbmbuf type MINOR: ncbmbuf: implement add MINOR: ncbmbuf: implement iterator bitmap utilities functions MINOR: ncbmbuf: implement ncbmb_data() MINOR: ncbmbuf: implement advance operation MINOR: ncbmbuf: add tests as standalone mode BUG/MAJOR: quic: use ncbmbuf for CRYPTO handling Aurelien DARRAGON (1): BUG/MINOR: sink: retry attempt for sft server may never occur Christopher Faulet (2): BUG/MINOr: hlua: Fix receive from HTTP applet by properly accounting data BUG/MEDIUM: apppet: Improve spinning loop detection with the new API Frederic Lecaille (4): TESTS: quic: useless param for b_quic_dec_int() BUG/MINOR: quic: too short PADDING frame for too short packets BUG/MINOR: quic: SSL counters not handled BUG/MAJOR: quic: uninitialized quic_conn_closed struct members Olivier Houchard (2): BUG/MEDIUM: stick-tables: Don't forget to dec count on failure. BUG/MEDIUM: mt_list: Make sure not to unlock the element twice Remi Tricot-Le Breton (3): BUG/MINOR: ssl: Free global_ssl structure contents during deinit BUG/MINOR: ssl: Free key_base from global_ssl structure during deinit BUG/MINOR: ssl: Potential NULL deref in trace macro Valentine Krasnobaeva (1): MINOR: debug: add distro name and version in postmortem William Lallemand (14): BUG/MINOR: acme: avoid overflow when diff > notAfter BUG/MINOR: ssl: leak in ssl-f-use BUG/MINOR: ssl: leak crtlist_name in ssl-f-use BUILD: ssl: can't build when using -DLISTEN_DEFAULT_CIPHERS MINOR: acme: acme-vars allow to pass data to the dpapi sink MINOR: acme: check acme-vars allocation during escaping CLEANUP: acme: acme_will_expire() uses acme_schedule_date() MINOR: acme: provider-name for dpapi sink BUILD: acme: fix false positive null pointer dereference MINOR: acme: implement "reuse-key" option MEDIUM: acme: don't insert acme account key in ckchs_tree BUG/MINOR: acme: memory leak from the config parser MINOR: acme: add the dns-01-record field to the sink MINOR: acme: display the complete challenge_ready command in the logs Willy Tarreau (10): BUG/MEDIUM: ssl: take care of second client hello BUG/MINOR: ssl: always clear the remains of the first hello for the second one BUILD: makefile: disable tail calls optimizations with memory profiling BUG/MEDIUM: pools: fix crash on filtered "show pools" output BUG/MINOR: pools: don't report "limited to the first X entries" by default BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id DOC: clarify the experimental status for certain features BUG/MEDIUM: threads/config: drop absent threads from thread groups BUG/MEDIUM: cli: also free the trash chunk on the error path BUG/MEDIUM: build: limit excessive and counter-productive gcc-15 vectorization ---
