GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL QUIC: unthrottled RETIRE_CONNECTION_ID backlog lets a peer force ~400MB of allocation

CVSS 7.5CVE-2026-84784Kernel, userspace & hypervisorcurated

Impact

The OpenSSL QUIC stack emits a RETIRE_CONNECTION_ID frame for every NEW_CONNECTION_ID it receives and retires the destination connection ID immediately instead of waiting for the ACK, so the limit on how many connection IDs a peer may issue is never enforced. A peer that floods NEW_CONNECTION_ID frames while withholding ACKs grows the control frame queue until roughly 400MB is allocated for a single connection, depending on ACK delay. On a shared node that is a memory-pressure lever against any QUIC-speaking daemon - an HTTP/3 front end or gateway - and enough of them will bring the OOM killer to a host that also holds GPU workloads. Availability only.

Who can reach it

Any remote peer able to establish a QUIC connection to an OpenSSL-based endpoint. No authentication required. Only deployments that actually use OpenSSL's QUIC implementation are affected.

What to do

Take the fixed OpenSSL release from the 2026-09-29 advisory and restart every QUIC-facing service; the advisory text given here does not name a fixed version number, so check it before scheduling. Disabling QUIC/HTTP/3 on exposed listeners is an effective stopgap. The FIPS module is outside the QUIC code.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.