Chrisvest

The `NoQuicTokenHandler` component fails to properly validate tokens when no specific token handler is set by the application. Specifically, the `validateToken()` function unconditionally returns 0, which the `QuicheQuicServerCodec.handlePacket()` function interprets as a valid token. This allows an attacker to spoof a victim's source IP address and include any non-empty token bytes in an Initial packet. Consequently, the server treats the victim's address as validated, bypassing the 3x anti-amplification send limit defined in RFC 9000 §8.1. This enables the server to reflect full-size handshake flights, such as certificates, toward the victim without the standard amplification restrictions.

A flaw in the netty-codec-haproxy component of the Netty network application framework allows a remote attacker to cause a Denial of Service (DoS) condition. By sending a specially crafted HAProxy message with a malformed PP2 TYPE SSL TLV (Type-Length-Value) header where the length is set below 5, the `readNextTLV()` function in `HAProxyMessage` triggers an IndexOutOfBoundsException. Because the `HAProxyMessageDecoder` only catches `HAProxyProtocolException`, this exception propagates, preventing the release of retained memory on the pooled cumulation buffer and leading to a memory leak.

An uncontrolled memory allocation issue exists in the `SslClientHelloHandler.decode()` function. When a ClientHello does not fit in the first record, the system eagerly allocates memory using `ctx.alloc().buffer(handshakeLength)` based on the 24-bit TLS handshake length. Because the `SniHandler`, `AbstractSniHandler`, and related constructors often set `maxClientHelloLength` and `handshakeTimeoutMillis` to 0, the length guard is disabled and no timeout is scheduled. Consequently, a request of 16 MiB or larger exceeds the default pooled chunk size, resulting in an immediate huge or unpooled allocation that is retained until the channel closes.

A file descriptor leak occurs in the `netty unix socket recvFd` function when a peer sends two file descriptors simultaneously via an SCM RIGHTS control message. The system allocates a control buffer of 24 bytes on 64-bit Linux, which exactly fits a control message containing two integers. Because the kernel installs both descriptors without triggering a `MSG CTRUNC` flag, a subsequent length check `cmsg->cmsg len == CMSG LEN(sizeof(int))` fails as it expects 20 bytes. This causes the application to skip the logic that reads the descriptor and fails to close the installed descriptors. The process then exits the read loop normally, resulting in two leaked file descriptors per message. This issue is reachable via `Epoll`/`KQueue` `DomainSocketChannel` when the application is configured with `DomainSocketReadMode.FILE DESCRIPTORS`.

A remote attacker can cause a Denial of Service (DoS) by sending specially crafted, non-complete Stream Control Transmission Protocol (SCTP) message fragments. The issue occurs because the handler uses `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))` for each non-complete fragment, creating a new CompositeByteBuf that wraps the previous accumulator. This results in an N-deep chain of composites where `readableBytes()` or `getBytes()` calls recurse N levels. Since there are no limits on the number of fragments, total bytes, or the number of `streamId` entries an attacker can open, a peer that never sets the `complete` flag can cause unbounded memory growth and excessive system resource consumption.

In the network application framework, `DefaultHttp2Connection.DefaultEndpoint` initializes `maxActiveStreams` and `maxStreams` to `Integer.MAX VALUE`, while `Http2Settings` does not insert `SETTINGS MAX CONCURRENT STREAMS` by default. If the application does not explicitly call `initialSettings().maxConcurrentStreams(n)`, the HTTP/2 server advertises and enforces no limit on concurrent streams. This allows a single TCP connection to create hundreds of thousands of long-lived stream objects, as each open stream allocates a `DefaultStream` object, `PropertyMap` slots, flow-controller state, and an `IntObjectHashMap` entry. This condition also enables Rapid-Reset amplification, where the lack of a low concurrent cap increases the workload on the backend.

The RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in the `depths` field but lacks `channelInactive`, `handlerRemoved`, or `exceptionCaught` methods to release them during pipeline teardown. Since the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent these chunks from returning to the JVM-wide direct-memory pool. Continuous connection churn by a network peer drains this shared pool, leading to allocation failures across all Netty channels in the process.

The `DelegatingDecompressorFrameListener` class manages HTTP/2 decompression by using a per-stream `EmbeddedChannel` to run decompression codecs such as gzip, deflate, or zstd. Decompressed chunks are handled as pooled `ByteBuf` objects and passed to an anonymous `ChannelInboundHandlerAdapter` tail handler responsible for their release. A remote peer can send specifically crafted frames that cause the flow-controller to throw an exception, triggering a resource leak. This leak can lead to an OutOfMemoryError (OOME), potentially crashing the Java Virtual Machine (JVM).

The HAProxy PROXY protocol v2 codec leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2 TYPE SSL` TLVs (type-length-value records) at depth two or greater. This occurs during the successful parse path where the underlying cumulation buffer, a pooled and potentially direct `ByteBuf` allocated by the channel, remains permanently pinned even after the `HAProxyMessage` is released and the decoder removes itself.

Netty is a network application framework used for developing protocol servers and clients. The `SimpleTrustManagerFactory.engineGetTrustManagers()` function and related paths wrap user-supplied plain X509TrustManager in X509TrustManagerWrapper. This wrapper extends X509ExtendedTrustManager but implements the 3-argument `checkServerTrusted(chain, authType, SSLEngine)` function by discarding the `SSLEngine` and calling the 2-argument delegate. Because the object is identified as an X509ExtendedTrustManager, internal wrappers from SunJSSE or Netty do not re-wrap it to add endpoint-identification. This results in a failure to perform hostname verification when a client is built using `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`, even if `endpointIdentificationAlgorithm` is set to "HTTPS" by default, potentially enabling man-in-the-middle attacks.

Before reading the first request-line, the `HttpObjectDecoder` function silently skips all whitespace and every byte for which `Character.isISOControl(b)` is true (0x00–0x1F and 0x7F). This behavior deviates from RFC 9112 §2.2, which only permits servers to ignore empty CRLF lines preceding the request-line to handle HTTP/1.0 POST workarounds. By absorbing non-CRLF control characters such as NUL, SOH, and STX, the software can be exploited for request-boundary confusion in pipelined or multiplexed transports. This occurs when a front-end component, such as a load balancer or TLS terminator, treats these bytes differently than Netty, potentially leading to request-desync or smuggling attacks.

The issue is related to an unsafe reading of environment files, which could potentially cause a denial of service in Netty. When loaded on a Windows application, Netty attempts to load a file that does not exist. If an attacker creates a large file, the Netty application may crash. A similar issue was previously reported, but the fix was incomplete, as null-bytes were not counted against the input limit. The vulnerability is related to the `BufferedReader.readLine()` function and the `InputStreamReader`, which can fill up the line-buffer with replacement characters when encountering null-bytes.