Loading story…
Netty merged a fix for a concurrency flaw in its adaptive allocator after maintainers found that BuddyChunk.remainingCapacity() was mutating allocator state while reading it. The method drained entries from freeList without exclusive access, which could trigger racy updates to the buddies array and lead to rare assertion failures and allocator state corruption under concurrent use.
The patch changes BuddyChunk.remainingCapacity() to a non-mutating implementation that calculates free capacity by summing queue contents instead of consuming them, and adds a weakPeekReduce method to MpscIntQueue to support the new behavior. Netty also added a regression test that reproduced the bug before the fix and reported that the change eliminated buddies-array corruption; the update was merged into the 4.2 branch for inclusion in 4.2.14.Final, then ported to Netty 5.0 and cherry-picked into another branch.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
The day after the 4.2 merge, Netty auto-ported the fix to Netty 5.0 and cherry-picked it into another branch. This extended the concurrency bug fix beyond the initial 4.2 branch.
Netty merged pull request #16777 into the 5.0 branch, bringing the adaptive allocator concurrency fix to the 5.0.0.Final milestone. The change made BuddyChunk.remainingCapacity non-mutating, added weakPeekReduce on MpscIntQueue, and included a regression test for buddies-array corruption and assertion failures.
Netty merged the adaptive allocator concurrency fix into the 4.2 branch, targeting release in version 4.2.14.Final. The patch included a regression test that reproduced the issue before the fix and reportedly eliminated buddies-array corruption.
Netty opened pull request #16767 to fix a concurrency issue in the adaptive allocator where BuddyChunk.remainingCapacity() modified internal state without exclusive access, causing racy updates and rare assertion failures. The change replaced the modifying implementation with a non-mutating capacity calculation and added support via weakPeekReduce on MpscIntQueue.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourcegithub.com
Open sourceredirect.github.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Netty merged fixes to limit memory allocation in its Brotli and Zstandard HTTP decompression paths after identifying denial-of-service risks from attacker-controlled compressed input. One change passes `HttpContentDecompressor`'s `maxAllocation` setting to `BrotliDecoder` and `ZstdDecoder`, bringing them in line with gzip and zlib handling and reducing exposure to zip-bomb-style memory exhaustion in constrained environments. A second change adds a `maxWindowLog` parameter to `ZstdDecoder` so oversized Zstandard frames can be rejected before large native-memory allocations occur. The Zstandard issue stemmed from `libzstd` allocating memory based on a frame's declared window size before decoding, allowing a small malicious frame to force large per-stream allocations and potentially crash servers. Netty set `DEFAULT_MAX_WINDOW_LOG = 27`, validated configurable values in the range `10` to `31`, merged the changes into the 4.2 branch, and ported them to 4.1 and 5.0. The protections shipped in **Netty 4.2.15.Final**, alongside other security fixes, and downstream projects including **Apache Spark** and **ArcadeDB** moved to upgrade to consume the release.
Jun 29, 2026
Netty disclosed and fixed **CVE-2026-48059**, a memory leak in its HAProxy PROXY protocol v2 codec that can let remote clients exhaust server memory by sending syntactically valid headers with nested `PP2_TYPE_SSL` TLVs at depth two or greater. The flaw leaves the underlying pooled `ByteBuf` cumulation buffer permanently pinned even though parsing completes successfully and no exception is raised, creating an availability risk rather than a confidentiality or integrity impact. The issue affects Netty releases before `4.1.135.Final` and `4.2.15.Final`, and the project published fixes in those versions alongside a GitHub security advisory. Separately, Netty also merged a non-security correction for `memoryAddress()` handling in wrapped direct `ByteBuffer` paths when `Unsafe` is disabled, shipping that consistency fix in `4.2.14.Final` and auto-porting it to Netty 5.0, but the HAProxy memory-exhaustion bug is addressed in the later `4.2.15.Final` release.
Jun 29, 2026
Netty fixed a QUIC race condition in `QuicheQuicChannel` that could notify a close promise before pending writes had completed, allowing a parent socket to close while data was still in flight. In affected cases, especially with pending `SENDMSG` operations on `io_uring`, the remote peer could miss the QUIC `CONNECTION_CLOSE` frame, leading to improper connection shutdown behavior. The fix, tracked under issue `#16718` and merged through pull request `#16758`, changes shutdown handling to ensure writes finish before close notification is delivered. Netty also added a unit test that simulates delayed writes and the raced close path, and shipped the correction in **Netty 4.2.14.Final**; downstream projects including ArcadeDB subsequently updated dependencies to consume the patched release.
Jun 29, 2026