]> git.kaiwu.me - haproxy.git/commit
BUG/MEDIUM: payload: validate SNI name_len in req.ssl_sni
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 7 Apr 2026 07:48:08 +0000 (09:48 +0200)
committerWilliam Lallemand <wlallemand@haproxy.com>
Tue, 7 Apr 2026 08:50:04 +0000 (10:50 +0200)
commited267f9bc541d5b0bb18b994e9336ba9d98927b5
treebc5608bdc6902e7ed3f10a26219b3014ec338713
parent41bded895292573a8fbe9817499c5e996fb5e4ea
BUG/MEDIUM: payload: validate SNI name_len in req.ssl_sni

The 16-bit name_len field is read directly from the ClientHello and
stored as the sample length without any validation against srv_len,
ext_len, or the channel buffer size. A 65-byte ClientHello with
name_len=0xffff produces a sample claiming 65535 bytes of data when
only ~4 bytes are actually present in the buffer.

Downstream consumers then read tens of kilobytes past the channel
buffer:
  - pattern.c:741 XXH3() hashes 65535 bytes -> ~50KB OOB heap read
  - sample.c smp_dup memcpy if large trash configured
  - log-format %[req.ssl_sni] leaks heap contents to logs/headers

Reachable pre-authentication on any TCP frontend using req.ssl_sni
(req_ssl_sni), which is the documented way to do SNI-based content
switching in TCP mode. No SSL handshake is required; the parser
runs on raw buffer contents in tcp-request content rules.

Bug introduced in commit d4c33c8889ec3 (2013). The ALPN parser in
the same file at line 1044 has the equivalent check; SNI never did.

This must be backported to all supported versions.
src/payload.c