Package Instance

Allocation of Resources Without Limits or Throttling
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. The `SniHandler` can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the `SniHandler` to allocate 16MB of heap. The `SniHandler` class is a handler that waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the `ClientHello` record. For this matter it allocates a `ByteBuf` using the value defined in the `ClientHello` record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the `SslClientHelloHandler`. This vulnerability has been fixed in version 4.1.94.Final.

HAProxyMessageDecoder Stack Exhaustion DoS
### Impact
A StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion.

### Patches
Users should upgrade to 4.1.86.Final.

### Workarounds
There is no workaround, except using a custom HaProxyMessageDecoder.

### References
When parsing a TLV with type = PP2_TYPE_SSL, the value can be again a TLV with type = PP2_TYPE_SSL and so on.
The only limitation of the recursion is that the TLV length cannot be bigger than 0xffff because it is encoded in an unsigned short type.
Providing a TLV with a nesting level that is large enough will lead to raising of a StackOverflowError.
The StackOverflowError will be caught if HAProxyMessageDecoder is used as part of Netty’s ChannelPipeline, but using it directly without the ChannelPipeline will lead to a thrown exception / crash.


### For more information
If you have any questions or comments about this advisory:
* Open an issue in [netty](https://github.com/netty/netty)