Package Instance

Unbounded queuing of path validation messages in cloudflare-quiche
### Impact
quiche v. 0.15.0 through 0.19.0 was discovered to be vulnerable to unbounded queuing of path validation messages, which could lead to excessive resource consumption.

QUIC path validation ([RFC 9000 Section 8.2](https://datatracker.ietf.org/doc/html/rfc9000#section-8.2)) requires that the recipient of a PATH_CHALLENGE frame responds by sending a PATH_RESPONSE. An unauthenticated remote attacker can exploit the vulnerability by sending PATH_CHALLENGE frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that PATH_RESPONSE frames can only be sent at the slower rate than they are received, leading to storage of path validation data in an unbounded queue.

### Patches
Quiche versions greater than 0.19.0 address this problem.

### References
[CVE-2023-6193](https://www.cve.org/CVERecord?id=CVE-2023-6193)
[RFC 9000 Section 8.2](https://datatracker.ietf.org/doc/html/rfc9000#section-8.2)

quiche connection ID retirement can trigger an infinite loop
## Impact

Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRE_CONNECTION_ID frames.

QUIC connections possess a set of connection identifiers (IDs); see [Section 5.1 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Once the QUIC handshake completes, a local endpoint is responsible for issuing and retiring Connection IDs that are used by the remote peer to populate the Destination Connection ID field in packets sent from remote to local. Each Connection ID has a sequence number to ensure synchronization between peers

An unauthenticated remote attacker can exploit this vulnerability by first completing a handshake and then sending a specially-crafted set of frames that trigger a connection ID retirement in the victim. When the victim attempts to send a packet containing RETIRE_CONNECTION_ID frames, [Section 19.16 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-19.16) requires that the sequence number of the retired connection ID must not be the same as the sequence number of the connection ID used by the packet. In other words, a packet cannot contain a frame that retires itself.  In scenarios such as path migration, it is possible for there to be multiple active paths with different active connection IDs that could be used to retire each other. The exploit triggered an unintentional behaviour of a quiche design feature that supports retirement across paths while maintaining full connection ID  synchronization, leading to an infinite loop.

## Patches

quiche 0.24.5 is the earliest version containing the fix for the issue