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.
Once the TLS handshake completes, QUICConn.HandleData buffers data and passes it to handlePostHandshakeMessage every time the buffer contains a complete message. The size check is wrong, however, so it can pass along a partial message, triggering a panic when handlePostHandshakeMessage tries to read the remainder of the message.
In addition, HandleData doesn't limit the amount of data it can buffer. It should reject messages larger than maxHandshake.
Normally, we'd consider this a PRIVATE track vulnerability, but this is a very new API and the only known user (quic-go) has already released a workaround in a patch release, so we're calling it PUBLIC track.
The check for fragmentary post-handshake messages in QUICConn.HandleData
was reversed, resulting in a potential panic when HandleData receives
a partial message.
In addition, HandleData wasn't checking the size of buffered
post-handshake messages. Produce an error when a post-handshake
message is larger than maxHandshake.
TestQUICConnectionState was using an onHandleCryptoData hook
in runTestQUICConnection that was never being called.
(I think it was inadvertently removed at some point while
the CL was in review.) Fix this test while making the hook
Run-TryBot: Damien Neil <email@example.com>
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Marten Seemann <email@example.com>
Reviewed-by: Roland Shoemaker <firstname.lastname@example.org>
(cherry picked from commit e92c0f8)
Auto-Submit: Dmitri Shuralyov <email@example.com>
LUCI-TryBot-Result: Go LUCI <firstname.lastname@example.org>