Alexandr Nedvedicky

An inefficient algorithmic complexity issue exists in the QUIC stream reassembly process. OpenSSL uses a doubly-linked list to manage received QUIC stream fragments; while append operations are optimized, any fragment that does not immediately follow the current `tail` triggers a head-to-tail linear search. A remote peer that has completed the handshake can manipulate the sequence of offsets using compliant STREAM frames within the advertised receive window to force the server into O(n^2) operations. This results in progressive performance deterioration and excessive CPU pressure, potentially leading to a Denial of Service with low attacker bandwidth.

The QUIC process may retain memory for packet buffers longer than necessary. A remote peer can exploit this by sending maliciously crafted packets, forcing the local QUIC stack to keep packet buffer memory allocated for a duration controlled by the attacker. This occurs because the QUIC stack leaves stream data on the packet buffer to avoid a copy operation until the data is moved to a buffer provided by the local receiving application. This design allows an attacker to allocate significantly more memory than required by the data in the receiving stream buffer, leading to allocation of resources without limits or throttling.

The QUIC stack fails to enforce connection-level flow control for streams, although it correctly enforces stream-level limits. A remote peer can bypass the intended connection flow control window (default 768 KiB) by opening multiple streams that each remain within their individual stream-level limits. This allows a remote peer to force the local stack to allocate approximately 100MB of heap memory per connection, as the allocation is calculated as 2 x `MAX STREAMS` x (stream flow control limit).

A malicious remote peer can flood the local QUIC stack with `NEW CONNECTION ID` frames by bypassing the limit check on the number of connection IDs the remote stack can use. The local stack responds to each `NEW CONNECTION ID` frame by sending a `RETIRE CONN ID` frame via the Control Frame Queue (CFQ). If the remote peer withholds ACKs, the local stack can be forced to allocate approximately 400MB of memory. This occurs because the stack incorrectly retires the destination CID immediately upon receiving the `NEW CONNECTION ID` frame, rather than waiting for an ACK for the `RETIRE CONNECTION ID` frame as required by RFC 9000.

A double free issue exists in the QUIC server when processing an INITIAL packet. The default packet handler `port default packet handler()` creates a QRX (QUIC record layer RX) object for packet validation. If the subsequent channel creation via `port bind channel()` fails, the QRX object is freed. However, `port default packet handler()` also attempts to free the same QRX object upon detecting the failure, leading to heap corruption and a Denial of Service (DoS) through process termination. This condition can be triggered by sending a malformed INITIAL packet where the `DCID` (destination connection ID) is shorter than 8 bytes, causing `port bind channel()` to fail after `ossl quic lcidm enrol odcid()` detects the invalid length.

An OpenSSL QUIC server can allocate and queue new incoming channels without enforcing a limit when processing valid QUIC Initial packets for unknown destination connection IDs. The system uses the `Connection-Id` from the packet header to locate an existing connection; if none is found and the packet type is INITIAL, a new channel object is allocated and queued to be accepted by the local application via the `SSL accept()` function. If the application cannot call `SSL accept()` frequently enough, the memory used for these channel objects can grow without bounds, potentially leading to a Denial of Service by making the QUIC listener unavailable.

A remote peer can cause unbounded memory allocation leading to a Denial of Service and abnormal termination of an application acting as a QUIC client or server. This occurs when a malicious peer floods the local QUIC stack with PATH CHALLENGE frames. The stack allocates a PATH RESPONSE frame for every received PATH CHALLENGE, but these frames are only freed once the remote peer acknowledges their reception, which a malicious actor will not do, resulting in heap memory exhaustion.

An uncommon configuration of clients performing DANE TLSA-based server authentication, when paired with uncommon server DANE TLSA records, may result in a use-after-free and/or double-free on the client side. A use after free can lead to data corruption, crashes, or arbitrary code execution. The issue affects clients that use TLSA records with both PKIX-TA(0/PKIX-EE(1)) and DANE-TA(2) certificate usages. Clients that treat PKIX TLSA records as unusable or support only PKIX usages are not vulnerable. The client must also communicate with a server publishing a TLSA RRset with both types of TLSA records.