Valkey 8.0.2 repairs Lua shutdown and memory ownership

Closing a scripting runtime requires more care than releasing its remaining allocations. Destructors can still refer to objects while the runtime tears itself down, so the garbage collector must preserve the state those callbacks expect. The Lua correction in Valkey pull request 1513 resets collector state before closing the VM. Its purpose is to prevent userdata from being freed while destructor callbacks can still use it. That change is part of today's security release, Valkey 8.0.2.

The release announcement identifies the Lua problem as CVE-2024-46981 and says scripting commands may lead to remote code execution. It also fixes CVE-2024-51741, a denial-of-service problem involving malformed ACL selectors. Maintainers recommend applying the update as soon as possible. These are separate defects with different entry points, despite arriving in the same patch.

I default to Valkey when Redis semantics are wanted, and compatibility is a substantial part of that preference. This release is a reminder that preserving scripting behavior also preserves responsibility for the embedded runtime. Familiar commands do not make the implementation behind them exempt from memory-safety failures.

Lua shutdown has its own lifetime rules

The collector implementation shipped in 8.0.2 makes the relevant complexity visible. Collection has distinct propagation, sweeping and finalization states. Objects can remain reachable through structures that the collector revisits, and finalization has separate work associated with userdata. A shutdown path cannot assume that every object which appears ready for reclamation is already irrelevant to callbacks.

The repair's explanation is specific about the ordering failure. Userdata can be freed incorrectly while destructors may still use it, and resetting the collector state before closing the VM addresses that condition. This is an object-lifetime defect inside native runtime code. It is different from an ordinary Lua exception that a script can catch and report to its caller.

That distinction explains the severity assigned in the release notes. A scripting interface normally describes operations on database values. Native memory corruption can affect the process implementing that interface. The release identifies remote code execution as a possible consequence, which makes treating the defect as an application-level script failure an inadequate response.

The public patch description does not provide grounds for claiming that every script invocation executes arbitrary native code. Nor does it establish that every deployment has suffered exploitation. The concrete facts are the affected runtime behavior, the possible consequence stated by the maintainers, and the shipped correction. Those facts are sufficient to justify prioritizing the release without inventing an exploit narrative.

There is also a useful maintenance detail in the patch history. The Valkey change credits a correction published by Redis in its OSS branch. Shared implementation history allows a repair to benefit both projects when the relevant code and licensing permit it. Independent release processes still require each project to integrate and distribute the correction for its own users.

ACL syntax must fail before it becomes server state

The ACL correction in pull request 1514 concerns read and write key-pattern selectors. Its explanation says key-based access needs the ~ marker to configure the prefixes to which the selector applies. If that marker is missing, a server assertion can trigger later. The release categorizes the resulting problem as denial of service.

The timing matters. Invalid configuration reaching an assertion later in processing means the parser accepted a state that subsequent code could not safely interpret. The corrective boundary is the syntax check, before that malformed selector becomes usable server state. This is why an ACL-related security issue can concern availability even though ACLs are usually discussed as authorization controls.

An assertion is useful for detecting an implementation invariant that has already failed. It is a poor substitute for rejecting an invalid externally supplied selector. The patch moves responsibility to the point where the input's required structure can be established. That is a concrete distinction between validating a policy expression and discovering its invalidity during later use.

The two CVEs should therefore remain separate in an upgrade explanation. One concerns the lifetime of Lua userdata during runtime shutdown. The other concerns accepting malformed ACL syntax which can later terminate the server. Describing both merely as scripting hardening would hide the administrative input path involved in the second defect.

Defragmentation must update every retained reference

Another repair in this release concerns a dictionary structure that active defragmentation can relocate. The explanation in pull request 1512 describes a list of dictionaries undergoing active rehashing. The incremental rehashing routine walks that list and operates on the dictionary pointer stored in each node. Defragmentation can replace the allocation containing the dictionary while that dictionary remains registered in the list.

Updating the main database reference is insufficient in that situation. The rehashing list still contains the previous address, so later work can use a pointer whose allocation has moved. The correction updates the list node with the dictionary pointer returned after defragmentation. It preserves agreement between two structures that refer to the same logical dictionary.

The release notes mention potential memory corruption when databases are emptied while active defragmentation runs. The patch explanation supplies the mechanism behind that terse description. A background maintenance list retains an address, another maintenance operation relocates the object, and the retained address needs repair. Neither operation is inherently wrong when considered alone.

A related fix addresses script-cache eviction. Pull request 1310 describes scripts indexed by SHA1 in a dictionary, with a separate least-recently-used list tracking eviction order. The list could retain a string pointer that active defragmentation had already moved or freed. Eviction would subsequently encounter the invalid relationship between the list entry and the dictionary.

That repair takes a different approach. It duplicates the script identifier when adding it to the LRU list, so the list owns an independent string. The patch explains that dictionary unlinking does not require pointer identity, allowing the copied identifier to locate the appropriate entry. Independent ownership removes the dependency on the dictionary's string allocation remaining at one address.

Both corrections concern references outside an object's primary container. One preserves shared ownership by updating a secondary pointer. The other gives a secondary structure its own allocation. The appropriate choice depends on what the consumer needs, and the two patches make that difference concrete without changing the scripting commands applications issue.

I regard these fixes as relevant to Valkey's operational appeal. Compatibility reduces application migration work, but it leaves substantial implementation work in memory management. A patch that repairs these internal relationships can matter to an existing deployment without adding any new application command.

Replication loading also depends on explicit ownership

The release includes a TLS and dual-channel replication crash correction. Pull request 1173 introduces scoped handling of the server's loading context during RDB operations. It also adds a flag that signals an immediate abort, allowing loading to terminate when replication is cancelled after the main connection disappears.

The patch description identifies potential use-after-free behavior during that disconnection path. A loader has temporary access to a context whose lifetime depends on replication continuing. Cancellation has to reach the loader before it proceeds with resources that are no longer valid. Restoring the original loading context when the scope ends addresses another part of the same ownership problem.

That is separate from the replica loading performance repair in pull request 1199. The latter describes pre-created slot dictionaries failing to expand as intended, causing repeated rehashing during snapshot loading. It also corrects which slot count supplies database-sizing information while a replica is still synchronizing. The repair changes initialization work, rather than promising a general increase in command throughput.

A performance issue during synchronization has a different operational meaning from a steady-state throughput regression. Snapshot loading is part of bringing a replica into service. Repeated dictionary growth adds work during that process, and initialization errors can remain unobvious when they do not immediately change the final stored values. The patch explanation is useful because it identifies the extra work instead of presenting a benchmark percentage as a universal result.

Valkey 8.0.2 therefore has several reasons to matter beyond its two security identifiers. The Lua and ACL fixes determine the release's urgency. The supporting repairs address stale references and cancellation behavior in maintenance paths that operate beneath familiar database commands. An upgrade description can preserve that distinction while still explaining why a patch release changes the reliability of an otherwise unchanged workload.