Valkey 8.0.11 fixes RDMA cleanup and recovery persistence

A server can recover from a truncated append-only file, accept new writes and still lose those writes on the next restart. Valkey 8.0.11 fixes that persistence sequence alongside a security flaw in RDMA connection cleanup. The release therefore addresses both an immediate crash condition and a recovery error whose consequence appears later.

Valkey 8.0.11 was released on August 31. Its tagged notes mark it SECURITY urgency. The named security advisory concerns servers built with RDMA support and configured to use an RDMA listener.

I default to Valkey where Redis semantics are wanted, which makes maintenance on an existing release line relevant even when it adds no new application command. Recovery and connection cleanup are part of the behavior an application relies on. A process being available after restart is only one observation about that behavior.

The RDMA flaw has explicit prerequisites

GHSA-jcj7-v34w-v9vv describes an authenticated user freeing another client's connection while RDMA processes pending data. The transport could then dereference a dangling pointer.

The advisory limits exposure to builds using USE_RDMA with an RDMA listener configured. That listener is off by default and requires RDMA-capable hardware. A server version alone therefore does not establish whether this particular path is active.

The advisory also identifies two related defects. Iteration cached a next entry that a command handler could free. Separately, closing a connection left an entry in the pending list after freeing the connection. Later processing could encounter that stale entry.

The RDMA patch addresses the lifetime at several points. The event handler returns when the callback reports that the connection closed. Connection cleanup unlinks the pending-list node before freeing its connection.

Pending-data processing also stops retaining an iterator across calls to handlers. It takes the current head entry and bounds the loop by the list length observed on entry. A handler can then remove another connection without invalidating a cached next-node pointer.

This resembles the TLS pending-data correction already present in the project, but it applies to another transport implementation. A common connection interface does not guarantee that every transport implements the same cleanup ordering correctly.

An incomplete transaction needs an earlier truncation point

The AOF recovery patch concerns a short read while a MULTI/EXEC block is being loaded. The loader has a last valid file position and a position recorded before the transaction.

If the file ends inside that transaction, recovery needs to discard the entire incomplete block. Truncating at a later position can leave an uncommitted transaction prefix in the file. New commands appended after recovery then encounter the consequences of that surviving prefix on a subsequent replay.

The fix moves the transaction-state check into the unexpected-end-of-file path. When the loader is inside MULTI, it selects the position before MULTI as the valid truncation boundary. That applies even when a short read occurs while parsing a command.

This is a difference between a valid command prefix and a valid transaction boundary. A set of complete commands inside an unfinished transaction is not a completed transaction. Recovery has to account for the larger structure.

The patch also updates the valid position after reading an RDB preamble in an older-style AOF. The preamble's data needs to survive truncation of an incomplete command tail. Otherwise the recovery boundary could remove valid state that was loaded before the transaction.

A second restart makes the regression visible

The regression test builds an AOF with a completed write before MULTI and an incomplete EXEC at the end. On recovery, the earlier write must remain and the transaction's write must be absent.

The test then adds a new write and restarts again. That new value must survive the second replay. Without this step, the test could accept a recovery that looks correct in memory while leaving the persisted command sequence unsuitable for future recovery.

A companion case checks the RDB-preamble form. It verifies the preamble data, rejects the incomplete transaction and exercises another restart. The test sequence describes the persistence promise more accurately than checking whether the first startup succeeds.

I find that delayed observation particularly important. Recovery changes the file that future recovery will consume. Its correctness includes the state produced for the next startup, not only the state visible immediately after the current one.

The tests also distinguish discarded work from lost work. The incomplete transaction must not appear after recovery, while a write accepted afterward must persist. Treating both missing values as the same outcome would conceal the defect. Their positions in the execution history determine which result is correct, and the second restart checks that distinction against the recovered file.

Replaying history is different from authorizing a new request

A separate AOF ACL patch fixes another path to silent data loss. The internal client used for replay was subject to ACL checks during transaction execution.

The regression test disables the default user while providing another user for access. Writes outside a transaction and writes inside MULTI/EXEC must all reload. Before the fix, transaction execution could apply current ACL restrictions to persisted commands and omit their effects.

The change marks the AOF client as outside ordinary user ACL checking. That is specific to the internal replay client. It does not grant connected application users unrestricted access.

The distinction follows from the purpose of replay. Those commands represent the server's stored history. Reconstructing that history should not depend on whether the default user's current permissions would authorize a new external request.

These persistence corrections affect installations independently of the RDMA prerequisite. The security advisory identifies one transport configuration, while the AOF tests describe recovery paths involving partial transactions and ACL state. Together, the release's source changes establish more precise boundaries for both connection lifetime and reconstruction of persisted writes.