Search for packages
| purl | pkg:deb/debian/netty@1:4.1.48-4%2Bdeb11u1?distro=trixie |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-8p4t-8f51-h3dc | Uncontrolled Resource Consumption The Snappy frame decoder function does not restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well. This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk. |
CVE-2021-37137
GHSA-9vjp-v76f-g363 |
| VCID-m7b8-8zcj-uqey | Netty vulnerable to HTTP Response splitting from assigning header value iterator ### Impact When calling `DefaultHttpHeaders.set` with an _iterator_ of values (as opposed to a single given value), header value validation was not performed, allowing malicious header values in the iterator to perform [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting). ### Patches The necessary validation was added in Netty 4.1.86.Final. ### Workarounds Integrators can work around the issue by changing the `DefaultHttpHeaders.set(CharSequence, Iterator<?>)` call, into a `remove()` call, and call `add()` in a loop over the iterator of values. ### References [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting) [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html) ### For more information If you have any questions or comments about this advisory: * Open an issue in [[example link to repo](https://github.com/netty/netty)](https://github.com/netty/netty) * Email us at [netty-security@googlegroups.com](mailto:netty-security@googlegroups.com) |
CVE-2022-41915
GHSA-hh82-3pmq-7frp |
| VCID-qruf-r6dc-3ugj | 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) |
CVE-2022-41881
GHSA-fx2c-96vj-985v |
| VCID-swu5-a9h5-ffex | Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') This CVE has been marked as a False Positive and has been removed. |
CVE-2021-43797
GHSA-wx5j-54mm-rqqq |
| VCID-xyc4-63ra-mfh2 | Uncontrolled Resource Consumption The Bzip2 decompression decoder function does not allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack |
CVE-2021-37136
GHSA-grg4-wf29-r9vv |