GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL QUIC: missing connection-level flow control lets a peer force ~100MB of heap per connection

CVSS 5.3CVE-2026-75804Kernel, userspace & hypervisorcurated

Impact

The OpenSSL QUIC receive path enforces the per-stream flow-control limit but not the connection-level one. A remote peer that opens many streams, keeps each within its stream limit, and never sends the zero-offset byte (so the stack never consumes the buffered data) makes the local stack hold 2 x 100 streams x 512kB, roughly 100MB of heap per connection, instead of the advertised 768KiB window. Any service on the fleet terminating QUIC or HTTP/3 with OpenSSL can be pushed into memory exhaustion by a modest number of connections - a concern for ingress proxies and object-storage or model-download endpoints in front of GPU nodes, where an OOM kill is a service outage rather than a crash of one tenant's job. Confidentiality and integrity are untouched; this is availability only, and only for OpenSSL's own QUIC implementation. The FIPS module is out of scope for this issue.

Who can reach it

Any remote peer that can complete a QUIC handshake with an OpenSSL-based listener. No authentication required. Services that do not use OpenSSL's QUIC stack are unaffected.

What to do

Update the distribution's OpenSSL packages per the 2026-09-29 OpenSSL advisory and restart every process linked against libssl that terminates QUIC - services do not pick up the new library until restarted. No node reboot needed. Fixed version numbers are in the vendor advisory; the NVD record does not state them. As an interim measure, front QUIC listeners with per-source connection limits or disable HTTP/3 on exposed endpoints.

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.