Redis patches three lines at once: propagating a 4GB+ message over the cluster bus overflows the heap

Redis released 8.10.3, 8.8.4 and 8.6.8 on October 26, all fixing the same issue:

A heap buffer overflow when propagating a PUBLISH / SPUBLISH message larger than 4GB over the cluster bus in cluster mode.

Update urgency is marked SECURITY. It looks like a bug nobody can hit, but it is worth a post because the shape of the trigger conditions is instructive.

Unpacking the trigger

Four conditions must hold at once:

1. Cluster mode — standalone or primary/replica setups never touch the cluster bus;
2. PUBLISH or SPUBLISH is used — that is, pub/sub;
3. the message exceeds 4GB;
4. it is propagated over the cluster bus (the message crosses nodes).

The third is the key. A 4GB message is abnormal on its own:

# the default protocol limit is 512MB; normal traffic never approaches 4GB
redis-cli config get proto-max-bulk-len
# 1) "proto-max-bulk-len"
# 2) "536870912"

proto-max-bulk-len defaults to 512 MB. Sending 4 GB requires raising it first — so this is not a “anyone can trigger it” bug, it needs a relaxed configuration plus traffic that really sends giant messages.

Why “4GB” looks familiar

A 32-bit length field. Plenty of protocols encode lengths in 32 bits, maximum 4294967295 bytes — exactly 4GB minus one. Once a length computation crosses that boundary you get truncation or integer wraparound, followed by under-allocation and an out-of-bounds write.

The cluster bus has its own binary protocol, and messages get re-wrapped there. The overflow happens in that wrapping step: the internal representation fits (Redis strings use 64-bit lengths), the bus length field does not.

The general lesson: length validation across a protocol boundary must use the narrowest layer. Fitting 4GB internally does not mean the external protocol can express it.

Three lines at once says something

Redis now maintains 8.10, 8.8 and 8.6 in parallel. A security fix has to be applied three times, which is exactly why its patch releases always arrive as three versions on one day.

The action for users is simple: upgrade to the newest patch on your line. Which line you are on depends on your major version; crossing lines is not part of a security patch.

Beyond upgrading: who relaxed the config

The real hint here is not “upgrade fast” but who widened your configuration:

• proto-max-bulk-len raised past 4GB usually means someone wanted to move large objects — that is Redis being used as a message queue or object store;
• PUBLISH carrying large payloads means pub/sub is being used as a data channel, when it was designed for notifications, not data.

I put both into the config review checklist:

# keep the default or lower; use object storage for big blobs
proto-max-bulk-len 512mb
# a pub/sub message over 1MB means the design is wrong
client-output-buffer-limit pubsub 8mb 2mb 60

The second line is the backstop: even if someone does send a large message, the output buffer limit disconnects them before the node goes OOM.

One-line verdict

Narrow impact — cluster plus pub/sub plus a raised protocol limit. But narrow does not mean skip it: a security patch costs one rolling restart, not patching costs an unexplained segfault. And half of the trigger conditions here are configuration, which never fixes itself.