UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Example URL:
Steps to reproduce the problem:
QUIC accepts STREAM frames with an offset close to the maximum offset (max uint64), as long as the sum of the offset and the data contained in that frame overflows the uint64.
Chrome seems to store these frames until the corresponding stream is closed, allowing a peer to consume more memory than advertised by the flow control window.
What is the expected behavior?
A STREAM frame as described above should have caused a flow control violation.
A better solution is to reject STREAM frames that cause this overflow because according to the spec it's not allowed to send more than 2^64 bytes on a stream.
What went wrong?
see above
Did this work before? N/A
Chrome version: 56.0.2924.87 Channel: stable
OS Version: OS X 10.12.3
Flash Version:
quic-go had the same issue, see here: https://github.com/lucas-clemente/quic-go/issues/452
Comment 1 by nyerramilli@chromium.org
, Feb 28 2017