REDHAT-BUG-2536949: High severity Netty netty-codec-memcache vulnerability
Memcache binary codec signed/unsigned type mismatch causes frame desynchronization and response smuggling
A public GitHub Security Advisory (GHSA-wxrh-4rgq-pjcg) describes the following issue:
Vulnerability
In the Memcache binary protocol codec, keyLength and extrasLength are read as signed Java types (readShort() / readByte()) but the Memcache binary protocol specifies them as unsigned (uint16 / uint8).
BinaryMemcacheRequestDecoder.java:42-43: java header.setKeyLength(in.readShort()); // signed: -32768..32767 (should be 0..65535) header.setExtrasLength(in.readByte()); // signed: -128..127 (should be 0..255)
AbstractBinaryMemcacheDecoder.java:86-92 — Extras check fails for values ≥ 0x80: java byte extrasLength = currentMessage.extrasLength(); if (extrasLength > 0) { // FALSE when byte value is 0x80-0xFF (seen as negative) currentMessage.setExtras(in.readRetainedSlice(extrasLength)); }
Line 118-120 — Value length arithmetic produces wrong result: java int valueLength = currentMessage.totalBodyLength() - currentMessage.keyLength() // negative if >= 0x8000 - currentMessage.extrasLength(); // negative if >= 0x80
Attack Scenario
Malicious memcache server sends response with extraslength = 0x80 (128 unsigned, -128 signed):
1. extrasLength > 0 → -128 > 0 → false → extras bytes NOT consumed from wire 2. valueLength = totalBody - key - (-128) = totalBody + 128 → reads 128 extra bytes from NEXT frame 3. Frame boundaries are now desynchronized 4. All subsequent responses are misinterpreted
Impact: Response smuggling in proxy/cache scenarios where one client's data bleeds into another's response stream.
Affected Code
- codec-memcache/.../BinaryMemcacheRequestDecoder.java:42-43 - codec-memcache/.../BinaryMemcacheResponseDecoder.java:42-43 - codec-memcache/.../AbstractBinaryMemcacheDecoder.java:86-92,101-109,118-120
Suggested Fix
Use readUnsignedByte() and readUnsignedShort(), store in int fields.
Affected: - maven:io.netty:netty-codec-memcache affected >= 4.2.0.Final, <= 4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-memcache affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-wxrh-4rgq-pjcg
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch GHSA-wxrh-4rgq-pjcg - Configuration
In AbstractBinaryMemcacheDecoder/BinaryMemcache{Request,Response}Decoder, change parsing so extras_length is read with readUnsignedByte() into an int (0..255) and keyLength is read with readUnsignedShort() into an int (0..65535), ensuring extrasLength > 0 logic uses the unsigned int values so extras bytes are consumed correctly and frame boundaries are not desynchronized.
Memcache binary protocol codec (netty-codec-memcache) use unsigned reads for extrasLength and keyLength (readUnsignedByte/readUnsignedShort) and store lengths in int fields = readUnsignedByte() and readUnsignedShort()
Event History
Frequently Asked Questions
What must an attacker be able to do to trigger this issue?
The attacker must be able to send crafted Memcache binary protocol frames to a component using the affected decoder. The crafted frame uses key-length values of at least 0x8000 and/or extras-length values of at least 0x80, which are interpreted as negative signed Java values.
What is the practical impact of the incorrect length handling?
The decoder can skip extras data or calculate an incorrect value length, causing protocol-frame desynchronization. This can enable response smuggling.