Redis 6.2.3 fixes allocation arithmetic in LCS and integer sets

An allocation function can receive a value of the correct type after the arithmetic that produced it has already overflowed. Redis 6.2.3 addresses that pattern in two places. One calculates the matrix used for longest-common-subsequence analysis. The other calculates the byte size of a compact integer set. The resulting vulnerabilities have different histories and different conditions for reaching the affected code.

The 6.2 release notes date the patch to May 3. The tagged notes classify it as a security update for affected authenticated client connections. They identify CVE-2021-29477 in STRALGO LCS and CVE-2021-29478 in COPY for large integer sets. Both can corrupt the heap and potentially permit remote code execution.

I have used Redis since its early releases, and its compact command model remains one of its attractions. These fixes show why evaluating a command also requires examining the sizes and representations it can reach. A familiar operation such as copying a set can exercise arithmetic that predates the command itself.

LCS allocates intermediate state from both inputs

The 6.2.3 string implementation accepts LCS inputs either as literal strings or through keys holding strings. It computes the longest common subsequence using a dynamic-programming table. Entries describe subsequence lengths for prefixes of the two inputs, so the table's dimensions depend on both string lengths.

The implementation stores that conceptual table in a linear array of uint32_t entries. If the input lengths are alen and blen, the allocation expression multiplies the corresponding dimensions and the size of an entry. This is intermediate storage required by the algorithm. It is distinct from the size of the final subsequence returned to the client.

The 6.2.2-to-6.2.3 changes add a size_t cast before the dimension multiplication. That placement matters. The multiplication needs the intended arithmetic type while it executes. Assigning its final result to a wider variable would not reconstruct bits already lost in an earlier, narrower operation.

The security issue is therefore about the relationship between intended storage and calculated storage. If the size calculation wraps, an allocation can be smaller than the algorithm expects while subsequent indexing still follows the intended matrix dimensions. The command's ability to accept strings is insufficient protection against that mismatch. The intermediate representation has its own sizing requirements.

The LCS advisory, published on May 3, identifies the vulnerability in Redis 6.0 and newer and names 6.2.3 and 6.0.13 as patched versions. It also documents an ACL-based mitigation that prevents clients from using the affected command. That guidance identifies both the maintained-line patches and a way to remove command access while arranging an upgrade.

Requesting a shorter answer does not remove the matrix

The source separates building the LCS table from choosing the reply. It supports returning the subsequence, its length, or matching-index information. The LEN option changes the requested result, but the table is still built before the implementation selects that reply. A small response does not imply small intermediate work.

This is useful operational context even apart from the memory-safety defect. An API can return one integer while computing a structure based on two input sizes. Reasoning only from response size would omit the allocation that the patch changes. The actual algorithm explains why input combinations matter.

The source also validates option combinations and input types. Those checks serve different purposes from the allocation correction. Rejecting incompatible reply options does not establish that matrix arithmetic is safe. Likewise, confirming that both keys contain strings does not establish that a product of their lengths fits the arithmetic used for storage.

I regard those distinctions as useful when reviewing a server command. Input types, accepted syntax and intermediate allocation sizes are separate conditions. The May patch concerns the arithmetic connecting valid input lengths to a concrete allocation, and its placement in the expression makes that correction visible.

COPY reaches the integer set's byte-length calculation

The second May 3 advisory concerns copying large integer sets. Its prerequisites include changing set-max-intset-entries from the default and constructing a sufficiently large integer-valued set. The advisory distinguishes the age of the arithmetic defect from the age of the command that exposes it.

COPY appears in Redis 6.2, while the notes trace the underlying integer overflow back to 2.6. In earlier versions, the defect could produce a corrupt RDB or DUMP payload. Those versions did not have the same COPY path. A statement that all versions had an identical remotely reachable copy vulnerability would erase that distinction.

The integer-set source calculates the blob length as the header size plus the number of elements multiplied by their encoding width. The patch casts the element count to size_t before multiplication. As in the LCS allocation, the location of the conversion affects the arithmetic that produces the size.

Here the dimensions describe one compact object's representation rather than a two-input dynamic-programming matrix. The common failure pattern is calculating a size in a type too narrow for the intended product. The practical exposure differs because reaching the relevant set size depends on a configuration change that the advisory names explicitly.

Command implementation determines what duplication means

The 6.2.3 COPY implementation dispatches duplication according to the source object's type. Strings, lists, sets and other built-in types have their own duplication routines. Module values use a module-specific path. The top-level command therefore depends on the size and copying rules of the actual representation it encounters.

The command first checks the source and destination. A missing source returns zero. An existing destination also returns zero unless replacement was requested. After successful duplication, it adds the new object and carries over an existing expiration time. These steps show that copying concerns a value and its associated key state, not a generic byte string returned to the client.

The integer-set flaw becomes relevant within that type-dependent duplication. A correct destination check does not validate an internal object's calculated blob size. The command's visible key semantics and the representation's byte arithmetic both need to be correct for the operation to be safe.

The advisory names preventing unprivileged users from changing set-max-intset-entries as a mitigation, using ACL restrictions on CONFIG SET. That targets the configuration prerequisite. It should not be confused with fixing the size calculation itself. The release supplies that code correction, while the mitigation limits one route to the vulnerable representation.

The same implementation rejects copying a key onto itself in the same database. It also rejects selecting another database in cluster mode. Those conditions describe valid use of the command and remain separate from the allocation defect. An application observing an error for one invalid destination cannot infer that every permitted source representation has safe size arithmetic. Conversely, the security correction does not remove these destination rules or change the meaning of replacement. Reading the command and the representation helper together identifies which checks protect key-level behavior and which calculation determines the memory used by the copied object.

Configuration access is part of the exposure

The two advisories consequently describe different temporary restrictions. The LCS mitigation restricts a command. For integer sets, the mitigation restricts changing a setting needed for the large representation. A broad statement that authentication alone resolves either problem would contradict the release notes, which explicitly classify affected authenticated connections as the security concern.

The patch also contains maintenance work outside these allocation changes. Its notes identify a monotonic-clock correction for Lua timeout checking and memory-leak fixes in module defragmentation and asynchronous client-tracking cleanup. Those changes have their own purposes and do not change the prerequisites named for the two CVEs.

For this release, the source-level lesson is specific. Both corrected expressions convert an operand before a multiplication used to calculate storage. The LCS path derives a table from two strings, while the integer-set path derives a blob size from count and encoding width. The advisories preserve the command and configuration conditions that determine which deployments can reach those calculations.