VDB
KO
HIGH 7.5

GHSA-6ghj-frrj-jjj3

Netty has Unbounded Direct Memory Consumption in its RedisDecoder

Details

### 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.

Are you affected?

Enter the version of the package you're using.

Affected packages

Maven / io.netty:netty-codec-redis
Introduced in: 4.2.0.Final Fixed in: 4.2.15.Final
Fix # pom.xml: bump <version>4.2.15.Final</version> for io.netty:netty-codec-redis
Maven / io.netty:netty-codec-redis
Introduced in: 0 Fixed in: 4.1.135.Final
Fix # pom.xml: bump <version>4.1.135.Final</version> for io.netty:netty-codec-redis

References