Cherry-pick of f3b6470 from unstable.
Skipped dual-channel-replication.tcl (lazyfree test doesn't exist on
9.0).

Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>

… (CVE-2026-23631) (#3627)

During a full sync, the functions/scripting engine is freed right before
loading the RDB from the primary. If a Lua script is still running and
yielding via the long-command mechanism at that moment, the freed engine
can be accessed when the script resumes, causing a use-after-free.

Add a guard at the top of replicaReceiveRDBFromPrimaryToMemory() to
check isInsideYieldingLongCommand() and return early, deferring the sync
processing until the script completes.

No validating test was added because the vulnerability is a race
condition between a yielding Lua script and a replication event handler,
which cannot be reliably triggered in a deterministic Tcl test.

Signed-off-by: ikolomi <ikolomin@amazon.com>
Co-authored-by: ikolomi <ikolomin@amazon.com>

…25243) (#3621)

Changes applied (3 files):

1. src/zipmap.c: Add sanity checks in zipmapValidateIntegrity() to
reject entries where the decoded length < ZIPMAP_BIGLEN (254) but the
encoding uses more than 1 byte. This prevents a pointer arithmetic
mismatch between validation and zipmapNext() that leads to heap buffer
over-reads.

2. src/rdb.c (hash zipmap conversion): Reorder the
hashtableAdd()/lpSafeToAdd() checks so lpSafeToAdd() is evaluated before
hashtableAdd() takes ownership of the field SDS. Add missing lpFree(lp)
in the error path to fix a memory leak when the conversion fails.

3. src/rdb.c (stream consumer PEL): Remove erroneous
streamFreeNACK(nack) in the "Duplicated consumer PEL entry" error path.
The nack is a shared reference from the global PEL (obtained via
raxFind), so freeing it here causes a double-free when the stream object
is later destroyed.

Test: added a regression test in tests/unit/dump.tcl that crafts a
RESTORE payload with a 2-entry zipmap where the first field uses an
overlong 5-byte length encoding for value 3. Post-patch, this is cleanly
rejected by zipmapValidateIntegrity(). Pre-patch, the misaligned
zipmapNext() reads garbage (confirmed via server log: "Hash zipmap with
dup elements, or big length (0)") which also produces an error, so the
test serves as a defense-in-depth regression anchor rather than a strict
pass/fail differentiator. The actual heap over-read is detectable with
AddressSanitizer builds.

Signed-off-by: ikolomi <ikolomin@amazon.com>
Co-authored-by: ikolomi <ikolomin@amazon.com>

…nt (CVE-2026-23479) (#3615)

When a blocked client is woken up on a key, unblockClientOnKey()
re-executes its pending command via processCommandAndResetClient(). That
function returns C_ERR when the client was freed as a side effect of the
re-execution (it detects this by server.current_client becoming NULL
inside freeClient()).

The pre-fix code ignored the return value and unconditionally accessed
c->flag.blocked / c->flag.module afterwards -- a use-after-free on the
freed client.

The fix mirrors the existing dead-client handling in
processPendingCommandAndInputBuffer() (src/networking.c): on C_ERR,
unwind the execution unit, restore server.current_client, and return
without touching c.

Note on testing: reaching the C_ERR branch requires the reprocessed
command to synchronously free the current client (for example a
replica/primary-link teardown or a module path that calls freeClient()).
None of the blocking commands routed through unblockClientOnKey
(BLPOP/BLMOVE/BRPOPLPUSH/BLMPOP/ XREADGROUP and friends) take that path
from a plain RESP client, so a Tcl-level integration reproducer is not
feasible without adding a test-only debug hook; this patch does not add
such a hook. A targeted gtest reproducer was also considered but
rejected as net-negative: it would require ~200 lines of fake-client
scaffolding to exercise a 7-line defensive guard and would become a
"change detector" as warned against in src/unit/README.md. The existing
tests/unit/type/list.tcl suite (288 tests) exercises the happy path of
this function and continues to pass unchanged. Running the suite under
AddressSanitizer (make SANITIZER=address) provides the strongest signal
against regressions of this class of bug.

Signed-off-by: ikolomi <ikolomin@amazon.com>
Co-authored-by: ikolomi <ikolomin@amazon.com>

Add a release notes entry for **Valkey 9.0.4** covering the three
security fixes being ported to the `9.0` branch:

- **CVE-2026-23479** — Use-After-Free in unblock client flow
- **CVE-2026-25243** — Invalid Memory Access in RESTORE command
- **CVE-2026-23631** — Use-after-free when full sync occurs during a
yielding Lua/function execution

Only modifies `00-RELEASENOTES`. The actual code fixes are in separate
PRs targeting `9.0`.

---------

Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>
Co-authored-by: Madelyn Olson <madelyneolson@gmail.com>