You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
QUIC stack must limit the number of PATH_CHALLENGE frames processed in RX
Currently local QUIC stack allocates PATH_RESPONSE frame for every
PATH_CHALLENGE frame it receives in single packet from its remote peer.
The memory with PATH_RESPONSE frame is released after local QUIC stack
receives an ACK which confirms reception of PATH_RESPONSE by remote peer.
This gives remote peer too much control over memory resources local
QUIC stack may consume.
Quoting RFC 9000 section 9.2.1:
...an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet.
Limiting the number of PATCH_CHALLENGE frames to 1 per QUIC packet received
helps to reduce heap memory overhead required to process PATH_CHALLENGE
frame.
Currently QUIC ACKM (ACK-manager) keeps all frames in retransmission
buffer until ACK is received. It can be changed such frames which
don't need to be ACKed don't need to be kept in retrans buffer,
those can be released right after transmission.
Fixes CVE-2026-34183
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
MergeDate: Mon Jun 8 14:43:13 2026
0 commit comments