Last Modified: Dec 18, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.0.1.3, 15.0.1.4, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2
Fixed In:
16.1.0
Opened: Jun 03, 2020 Severity: 3-Major
HTTP/2 protocol allows a negative flow-control window on initial stage of communication while first 65,535 bytes of payload are delivered from a peer. BIG-IP may break this requirement.
BIG-IP denies the POST request and sends RST_STREAM.
-- BIG-IP has a virtual server with http2 profile. -- A configured receive window size in the http2 profile is below 64K (default 32K). -- A peer sends POST request with payload exceeding initial receive window size over HTTP/2 connection.
None
BIG-IP allows a negative flow-control window on initial request allowing a peer to fill all 65,535 bytes of flow-control window even if it exceeds an advertised receive window size.
For an HTTP/2 client or a server BIG-IP may impose a delay up to 20 seconds if a peer sends 65,535 bytes of payload over a single stream and does not respond timely with SETTINGS/ACK frame to a SETTINGS frame sent by BIG-IP.