CVE-2022-2191

Vulnerability

Details

In Eclipse Jetty versions 10.0.0 through 10.0.9 and 11.0.0 through 11.0.9, the SslConnection class does not release ByteBuffers obtained from the configured ByteBufferPool when error code paths are taken during TLS handshake processing. This failure to deallocate buffers leads to a gradual accumulation of leaked memory within the pool [1][2]. The root cause is a missing cleanup step in the error-handling logic, which normally would return buffers to the pool for reuse.

Exploitation

An attacker can trigger this memory leak by initiating TLS handshakes that result in errors. For example, when the server requires client authentication and the client presents an expired or otherwise invalid certificate, the TLS handshake fails and the server-side error path does not release the ByteBuffers used to process the handshake [2]. No prior authentication is needed; the attacker only needs network access to the Jetty server to initiate TLS connections that will encounter errors.

Impact

Repeatedly triggering error paths causes the ByteBufferPool to become filled with leaked buffers, eventually exhausting the available memory. This can lead to degraded server performance or an out-of-memory condition, potentially resulting in denial of service. The vulnerability can be exploited without any special privileges beyond network connectivity [1][2].

Mitigation

The Jetty project has addressed this issue in versions 10.0.10 and 11.0.10 [2]. Users unable to upgrade immediately can apply a workaround by configuring a RetainableByteBufferPool with explicit memory limits (e.g., maxHeapMemory and maxDirectMemory) so that when the pool reaches capacity, further buffer allocations fall back to garbage-collectible objects instead of leaking unlimited memory [2]. The fix and workaround details are documented in the advisory [2] and the associated issue tracker [4].