]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: cache: fix a refcount leak for missed secondary entries
authorWilly Tarreau <w@1wt.eu>
Sat, 23 May 2026 20:31:58 +0000 (22:31 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 25 May 2026 08:52:42 +0000 (10:52 +0200)
commitf62d020140782ecdad79caa0b2e4163b54ca2163
tree84046e2ae352baa39f2a74af368824cc0c75577c
parentbbef74fb21c4a7af95f138476d4ce42c9e698a57
BUG/MEDIUM: cache: fix a refcount leak for missed secondary entries

When a primary cache hit has a Vary secondary_key_signature, the code calls
retain_entry() and shctx_row_detach() before performing the secondary lookup.
If get_secondary_entry() returns NULL (no stored variant matches), res is set
to NULL and the function falls through to return ACT_RET_CONT without calling
release_entry() or shctx_row_reattach(). Each such request leaks one refcount
and pins one shctx row permanently, eventually exhausting the cache if this
happens to all objects. This is visible when requesting a secondary key
covered by vary for an object that is already stored without that key.
"show cache" then shows the object's refcount increasing after each request.

In order to fix this we must do like when no secondary key could be built
and release everything. We only reattach to the row if we previously
detached.

The issue was introduced in 2.4 with commit 1785f3dd9 ("MEDIUM: cache: Add
the Vary header support"). The code changed a bit in 2.9 with commit
48f81ec09 ("MAJOR: cache: Delay cache entry delete in reserve_hot function"),
so in order to backport to 2.8 and older, the patch will have to be manually
applied (no test on detached).
src/cache.c