QUIC Transport Parameters Memory Leak During HelloRetryRequest in s2n-tls

**CVSSv3.1 Rating:** Medium **CVSSv3.1 Score:** 5.3 **CVSSv3.1 Vector String:** AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L **Summary** s2n-tls is an open source C99 implementation of the TLS/SSL protocols. An issue exists where a QUIC-enabled TLS 1.3 connection that goes through a HelloRetryRequest can cause one memory allocation to be leaked. **Impact** The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side, QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. AWS services that use s2n-tls have been updated to a patched version, and customers of those services do not need to take any action. Customers who use s2n-tls directly in their own applications should upgrade to the most recent release of s2n-tls. **Impacted versions:** <= v1.7.5 **Patches** The patch is included in s2n-tls version v1.7.6. **Workarounds** Deployments that do not enable QUIC are not affected and do not require any action. For QUIC-enabled deployments, restarting server processes periodically can reclaim the unreachable memory as a temporary mitigation. Otherwise, applications using s2n-tls should upgrade to the most recent release of s2n-tls. **References** If you have any questions or comments about this advisory, we ask that you contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

CVSS 3.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Severity from

GitHub (reviewed advisory)

• github.com/aws/s2n-tls/security/advisories/GHSA-cr7x-863j-xrc7
• github.com/aws/s2n-tls