netty-incubator-codec-ohttp's Incorrect Native Pointer Derivation in Pooled Direct ByteBuf Fallback Leads to Out-of-Bounds Native Memory Access
Moderate severity
GitHub Reviewed
Published
Jun 3, 2026
in
netty/netty-incubator-codec-ohttp
•
Updated Jun 11, 2026
Package
Affected versions
< 0.0.22.Final
Patched versions
0.0.22.Final
Description
Published by the National Vulnerability Database
Jun 4, 2026
Published to the GitHub Advisory Database
Jun 11, 2026
Reviewed
Jun 11, 2026
Last updated
Jun 11, 2026
The netty-incubator-codec-ohttp library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations, provides a fallback path for direct ByteBufs that do not expose their memory address through
hasMemoryAddress(). This fallback occurs whensun.misc.Unsafeis unavailable to Netty — for example, when the JVM is started with-Dio.netty.noUnsafe=true, when a SecurityManager restricts Unsafe access, or when running on non-HotSpot JVMs. In these configurations, Netty's defaultPooledByteBufAllocatorreturnsPooledDirectByteBufinstances for whichhasMemoryAddress()returns false.Why this matters: Under the enabling JVM configuration, an unauthenticated network attacker can cause the OHTTP gateway to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers by triggering cryptographic operations with crafted OHTTP requests. The corruption occurs regardless of whether the AEAD tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure path provides the attacker with the encryption key needed to extract the leaked data. This violates the confidentiality and integrity of all connections sharing the same Netty buffer arena.
References