GHSA-6ghj-frrj-jjj3
Netty has Unbounded Direct Memory Consumption in its RedisDecoder
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Maven | io.netty:netty-codec-redis | >= 4.2.0.Final, < 4.2.15.Final | 4.2.15.Final |
| Maven | io.netty:netty-codec-redis | < 4.1.135.Final | 4.1.135.Final |
Details
As written in the advisory (Markdown source, shown as plain text).
### Summary
An attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\r\n`. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.
### Details
io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the `decodeLength` method. This method reads bytes from the network until it encounters a `\n` character. However, it does not enforce any maximum length check while buffering the bytes if the `\n` character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., `$1111...`) without ever sending a `\n`.
To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them.
According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with `\r\n`. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without `\r\n` is a protocol violation and should be rejected immediately rather than buffered indefinitely.
### Impact
Denial of Service due to memory exhaustion. Any application using Netty's RedisDecoder to handle untrusted Redis traffic is vulnerable.
References
External links from the advisory. They lead to third-party sites.