Database/Kernel, userspace & hypervisor
OpenSSL QUIC: missing connection-level flow control lets a peer force ~100MB of heap per connection
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
- OpenSSL CMP client: NULL dereference when revoking a certificate by PKCS#10 CSRCVE-2026-75805 · OpenSSL CMP client (revocation-by-CSR response handling)Medium
- libuser: direct /etc/passwd rewrites can corrupt the account database and chain to local rootCVE-2015-3246 · libuser / usermode userhelper (/etc/passwd modification on RHEL)Medium
- Linux KVM/SVM - missing sev_decommission in sev_receive_start: KVM failed to DECOMMISSION the current SEV contextCVE-2021-47389 · Linux KVM/SVM - missing sev_decommission in sev_receive_startMedium
- QEMU VMDK driver: a crafted image causes an out-of-bounds read leaking 12 bytes or crashing the processCVE-2026-2243 · QEMU VMDK block driver (out-of-bounds read while parsing the image)Medium
- Linux kernel (drivers/iommu/amd): AMD-Vi updated the domain's I/O page-table mode before running the code that freesCVE-2022-48904 · Linux kernel (drivers/iommu/amd)Medium
- Linux kernel (drivers/iommu/amd): Unbinding a PASID races the I/O page-fault (PPR) notifications still in flightCVE-2023-53501 · Linux kernel (drivers/iommu/amd)Medium
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.