Redis 6.2.6 limits unauthenticated parsing and repairs size arithmetic

Authentication cannot protect work the server must perform before it can parse an authentication request. Redis 6.2.6 addresses that boundary by limiting some allocations for unauthenticated clients. The same release repairs several integer-overflow defects, including ones conditional on unusually large configuration limits. These issues share a maintenance release, but their exposure conditions need separate explanations.

The 6.2 release notes date the update to October 4. The tagged notes classify it as a security release and list eight CVEs. Some concern server request parsing or stored data representations. Another affects tools parsing replies from a server. Grouping every issue under authenticated command execution would misstate the request-parser flaw in particular.

I have used Redis since its early releases, and its protocol is part of what makes the system accessible. A small client interface still needs a careful resource contract at the parser. Before the server knows whether a command is permitted, it has already had to interpret enough input to identify that command and its arguments.

Request headers can commit memory before a command runs

The CVE-2021-32675 advisory explains that RESP requests specify element counts and element sizes. The server allocates memory based on those supplied values. Specially constructed requests across multiple connections can therefore consume substantial memory. The same parser handles authentication, making this issue reachable by unauthenticated users.

The advisory names 6.2.6, 6.0.16 and 5.0.14 as patched versions. Its mitigations prevent unauthenticated connections from reaching the server, through network controls or TLS that requires client certificates. A Redis password and a required TLS client certificate operate at different stages of accepting input, which is why the distinction matters for this particular parser problem.

The 6.2.5-to-6.2.6 changes add authentication-aware checks to processMultibulkBuffer. When authentication is required, a multibulk count greater than ten produces a protocol error. The parser also rejects a bulk length above 16384 under that condition. These are early bounds on unauthenticated input, rather than rules governing every authenticated command's maximum arity.

The helper authRequired makes the condition explicit. It considers whether the default user is active and marked nopass, along with whether the client has authenticated. A server configured for passwordless use does not acquire a meaningful unauthenticated stage merely because the patch contains these checks. The intended access configuration still determines whether the condition applies.

That detail also keeps the thresholds in context. They are not general recommendations for application payload size, nor do they imply that authenticated clients can allocate without other limits. The patch adds a narrower rule at a point where the parser has not yet established permission to execute ordinary commands.

A compact integer set has a separate resize calculation

The CVE-2021-32687 advisory concerns integer sets under a very large, non-default set-max-intset-entries setting. It describes possible heap corruption, disclosure or remote code execution through crafted set operations. Its temporary mitigation restricts unprivileged modification of that setting through access control on CONFIG SET.

The implementation diff changes intsetResize. Previously, the byte-size temporary was uint32_t, and multiplication occurred in that narrower representation. The patch computes the product in uint64_t after casting the element count. It also asserts that the computed data size fits within SIZE_MAX after reserving space for the integer-set header.

This correction concerns resizing a representation. It is distinct from the May correction to the helper that reports an integer-set blob's length. A data structure can have several size calculations, and repairing one helper does not establish that every other path uses sufficiently wide arithmetic. The October diff identifies another specific point where element count and encoding width become a storage size.

The configuration prerequisite limits the advisory's scope but does not make the arithmetic defect harmless. The setting permits the compact representation to grow much larger than its normal threshold. Restricting that setting changes which states unprivileged callers can reach. Applying the patch corrects the resize expression used when those states are considered.

Client tools parse a different direction of traffic

The CVE-2021-32762 advisory identifies an overflow in the hiredis reply parser used by redis-cli and redis-sentinel. It concerns large multibulk replies and a missing check before a calloc allocation. This is server-to-client input, so upgrading only an application server process is not a complete description of which affected executables exist in a deployment.

The advisory qualifies the platform exposure. Allocators that perform their own overflow checks prevent this path, and most modern systems have those checks. It also says Sentinel uses jemalloc by default, which is not vulnerable to this issue. The relevant conclusion depends on both the binary and its allocator, not simply the presence of Sentinel somewhere in an architecture.

I find that distinction especially useful when interpreting a security release with several affected components. The request parser consumes client input before authentication. A command-line client consumes a server reply. They require different descriptions of who supplies the bytes and which process performs the allocation.

Both advisories name the same maintained-line patch versions, but that shared version list does not make their mechanisms identical. One bounds pre-authentication request dimensions. The other corrects reply parsing on affected allocation environments. An inventory of components should retain that direction of trust.

Larger configuration limits expose representation boundaries

Other entries in the release notes also name non-default limits. CVE-2021-41099 involves string commands and network payloads when proto-max-bulk-len is manually set very high. CVE-2021-32627 involves streams with large values for both that setting and client-query-buffer-limit. These are conditions stated by the release, not assumptions that every deployment uses those values.

CVE-2021-32628 concerns ziplist-encoded structures under large non-default thresholds for hash or sorted-set entries and values. The thresholds decide when compact representations remain eligible. Changing them therefore affects the sizes the underlying representation can encounter, rather than merely changing an abstract performance preference.

The source diff also revises a guard in the shared dynamic-string growth code. It retains the requested new length separately from the later capacity calculation, then checks the header-plus-capacity allocation against that requested length. That separates the requested data requirement from the capacity chosen for growth. The assertion must compare quantities that still represent the intended request.

The patch's remaining security notes include a Lua-debugger heap-reading issue and a heap-buffer overflow involving specially crafted Lua scripts. Those mechanisms should not be inferred from the configuration prerequisites of the compact-data issues. The release lists them separately because access to different functionality supplies different routes to affected code.

Maintenance changes retain their own semantics

The release also corrects command behavior. Geographic store operations with an empty source delete the destination and return zero. That aligns the result with a store operation instead of returning the empty array associated with a non-store query. Client code relying on the old reply shape can observe a change independently of the memory-safety fixes.

Another note clarifies that PUBSUB NUMPAT reports the number of patterns rather than subscriptions. The notes say this behavior changed in 6.2.0 but was omitted from its documentation. It is a correction to the release history, not a newly introduced October behavior. Preserving that timing prevents the maintenance post from assigning the wrong trigger to an observed count.

Persistence receives a separate correction for macOS and FreeBSD using kqueue. The release notes say the always-fsync policy must guarantee the fsync before replying. That statement concerns acknowledgment timing. It does not derive from the request-parser limits or the compact-data allocation changes, even though all are distributed in the same update.

The networking diff also changes completion handling for blocked or paused clients. It returns before resetting their request state or advancing the applied replication offset, because the command has not yet been applied. This preserves the distinction between receiving bytes and completing an operation. The release notes separately identify a replication-offset problem when CLIENT PAUSE runs on a replica.

Redis 6.2.6 therefore requires component-specific interpretation. The parser repair matters before authentication, the integer-set repair depends on the compact representation's configuration and the client-library repair depends on allocator behavior. The source makes the early parser bounds and widened resize calculation visible, while the advisories identify the connection and configuration conditions under which each issue applies.