]> git.kaiwu.me - haproxy.git/commit
BUG/MEDIUM: stick-table: restrict key sizes to what fits in a buffer
authorWilly Tarreau <w@1wt.eu>
Tue, 29 Sep 2026 14:23:44 +0000 (16:23 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 29 Sep 2026 15:08:06 +0000 (17:08 +0200)
commitb224f63c103aff2e044841eb4aab5f887b028dae
treee40cb2233a2d214c71e7d0cbdadb34e38fbbdc58
parent8582635915d48966746cb3a7810771488a0eb9bb
BUG/MEDIUM: stick-table: restrict key sizes to what fits in a buffer

Dmitri Kaslov reported an interesting bug in the stick-table key exchange
over peers: the few extra bytes of overhead and data storage are not
accounted when building the key to be transmitted, while a message must
fit into a single buffer. This means in practise that a stick-table key
as large as a buffer can theoretically crash the sender. But it's not
that trivial since such a key has to be made (which wasn't the case in
1.4 when this was designed, rules and converters to do this weren't that
rich). For strings it doesn't happen by accident though, but nowadays
it's possible to do it by tracking too large data or even applying an
expansion converter (b64dec, hex etc). For binary it's easier because
the whole block is always padded with zeros and the whole size is sent.

It has become easier to trigger with large buffers because it's now
possible to wait for a large body and track it as a large key. During
local tests, mostly applet issues were noticed, with the peers applet
not being able to serialize its message and looping back there trying
again. But with ASAN it's visible that a few bytes are overwritten at
the end of the buffer.

In order to address this, here we apply a limit to what will be
serialized. For binary keys, that cannot be trimmed, we simply refuse
to start with too large a key + data storage for the buffer size,
explaining what to do to fix it (hint: nobody sane uses 16kB keys).
For strings, they're simply trimmed to the room left once data are
subtracted from the buffer size.

This is sufficient to stop this theoretical problem without affecting
peers transfers during an upgrade (no protocol change), nor affecting
anyone with a realistic configuration.

Thanks to Dmitri Kaslov for this report with a reproducer.

This should be backported to all stable releases, along with these two
previous commits:

  MINOR: stick-table: provide a function to estimate on-wire data size
  MINOR: stick-table: calculate the on-wire size of each key
src/stick_table.c