REDHAT-BUG-2536939: High severity Netty codec-stomp vulnerability
STOMP codec content-length long-to-int truncation causes infinite decode loop DoS
A public GitHub Security Advisory (GHSA-hmf3-49g9-g7qq) describes the following issue:
Vulnerability
In StompSubframeDecoder.java, the contentLength field is long (line 80) but alreadyReadChunkSize is int (line 78). At line 149, the remaining length is computed with a truncating cast:
java private long contentLength = -1; // long private int alreadyReadChunkSize; // int
// Line 149 int remainingLength = (int) (contentLength - alreadyReadChunkSize);
At line 233-238, getContentLength() accepts any non-negative long with no upper bound:
java private static long getContentLength(StompHeaders headers) { long contentLength = headers.getLong(StompHeaders.CONTENTLENGTH, 0L); if (contentLength < 0) { throw new DecoderException(...); } return contentLength; // No upper bound! Can be Long.MAXVALUE }
Attack Scenario
A STOMP frame with content-length: 2147483648 (Integer.MAXVALUE + 1):
1. contentLength = 2147483648L, alreadyReadChunkSize = 0 2. remainingLength = (int)(2147483648L) = -2147483648 (int truncation wraps negative) 3. toRead > remainingLength → any positive > -2147483648 → true → toRead not capped 4. (alreadyReadChunkSize += toRead) >= contentLength → small int vs huge long → false (never terminates) 5. alreadyReadChunkSize is int → eventually overflows, making termination impossible 6. Decoder produces chunks infinitely
Impact
- Infinite loop DoS: Decoder never finishes the frame, blocking all subsequent STOMP frames - Memory exhaustion: Chunk objects accumulate unbounded - CPU exhaustion: Endless decode iterations - Default configuration: No configuration changes needed
Affected Code
- codec-stomp/.../StompSubframeDecoder.java:78,80,149,233-238
Suggested Fix
Add upper bound in getContentLength(): java if (contentLength > Integer.MAXVALUE) { throw new DecoderException("content-length exceeds maximum"); } Or change alreadyReadChunkSize to long.
Affected: - maven:io.netty:netty-codec-stomp affected >= 4.2.0.Final, <= 4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-stomp affected <= 4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-hmf3-49g9-g7qq
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In StompSubframeDecoder.java, add an upper bound check in getContentLength() for StompHeaders.CONTENT_LENGTH so that content-length values that exceed Integer.MAX_VALUE cause DecoderException (e.g., 'content-length exceeds maximum') instead of allowing Long.MAX_VALUE.
STOMP codec (StompSubframeDecoder.java) getContentLength() upper bound for StompHeaders.CONTENT_LENGTH = Reject values greater than Integer.MAX_VALUE - Configuration
Change the alreadyReadChunkSize field from int to long so that comparisons like (alreadyReadChunkSize += toRead) >= contentLength terminate correctly and do not overflow.
STOMP codec (StompSubframeDecoder.java) alreadyReadChunkSize type/overflow handling = Use long (not int)
Event History
Frequently Asked Questions
What input is required to trigger the denial of service?
An attacker needs to send a STOMP frame whose content-length is at least 2147483648. This causes the long content length to truncate to a negative int during decoding, which can lead to an infinite decode loop.
Which deployments are exposed?
Deployments using Netty's codec-stomp component and accepting attacker-controlled STOMP frames are exposed. The provided information does not identify any configuration requirement beyond processing the crafted frame.
What can be done if patching is not immediately possible?
Reject or filter STOMP frames with content-length values greater than Integer.MAX_VALUE before they reach the vulnerable decoder. Enforce an upper bound on accepted content lengths to prevent the truncating cast from producing a negative remaining length.