commit 022c8636110ebac86a9b88724cda168ed713c21f [browse]
Author: Gopher Robot
Date: 2026-10-08 08:22:57 -07:00
[release-branch.go1.27] go1.27.2
Change-Id: Ic0b65cb1b99dfa414ec1c8b11360114db21b7530
Reviewed-on: https://go-review.googlesource.com/c/go/+/846986
Auto-Submit: Gopher Robot <gobot@golang.org>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
commit cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b [browse]
Author: Nicholas S. Husin
Date: 2026-09-21 10:47:27 -04:00
[release-branch.go1.27] net/http: apply header limits to Trailer headers too
When "Trailer" headers are sent by a client, the HTTP server internally
uses the header values to populate the Request.Trailer map passed to the
server handler. Because Request.Trailer is a map, each entry incurs
memory overhead. For HTTP/2 servers, a malicious client can exploit this
by sending a "Trailer" header that declares a large number of fields,
causing the server to allocate a disproportionate amount of memory while
bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.
This exploit is not applicable for HTTP/1 servers, which do not support
multiplexing a large number of requests over one TCP connection, and
whose Server.MaxHeaderBytes is calculated differently.
Fix this by applying MaxHeaderValueCount to the trailer fields declared
in the "Trailer" header in both HTTP/1 and HTTP/2, and MaxHeaderBytes in
HTTP/2.
Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for
reporting this issue.
Fixes CVE-2026-78659
For #81857
Fixes #81918
Change-Id: I01f52e9873be80ac72d88f9e4d96f6096a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5980
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847034
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
commit 12acaf3086437e140e2dd3b7d2c30fdd633c5fe0 [browse]
Author: Nicholas S. Husin
Date: 2026-09-28 10:23:32 -04:00
[release-branch.go1.27] net/http/internal/http2: prevent crash due to HPACK encoder race
Our HTTP/2 server could end up crashing due to inadvertently
modifying its HPACK encoder concurrently. This happens because the
server modifies the HPACK encoder from two goroutines without
synchronization: one uses the encoder to encode a HEADERS frame as part
of a response sent to a client and the other modifies the encoder's
table size when handling a SETTINGS frame containing
SETTINGS_HEADER_TABLE_SIZE that a client sends.
As a result, a malicious client can repeatedly send a request while
changing the header table size to crash the server.
Fix this issue by not applying SETTINGS_HEADER_TABLE_SIZE immediately.
Instead, buffer any SETTINGS_HEADER_TABLE_SIZE received, and only apply
the new value prior to the next time the server writes a frame.
Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for
reporting this issue.
Fixes CVE-2026-97032
For #81867
Fixes #81922
Change-Id: Ife977865a8bb190ae2cf6f462979ae406a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5940
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847033
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
commit 31dc9e2449e394439498142451627af52626d7c4 [browse]
Author: Damien Neil
Date: 2026-08-28 13:54:41 -07:00
[release-branch.go1.27] net/http/internal/http2: avoid 2x refund on stream close with buffered data
Fix the following bug:
- client opens a stream and sends data
- client resets the stream, and server refunds flow control
- handler reads the sent data, and server refunds flow control again
This double-refund allows a malicious client to exceed the server's
flow control limits, potentially causing the server to buffer much
more data than those limits should allow.
Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/)
for reporting this issue.
Fixes CVE-2026-78663
Fixes #81906
For #81743
Change-Id: I86159053f7ce509d1ee93de55697f7ef6a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6020
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847032
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
commit 1d58cdaa1069e259b60c324ec77472f09f23d92e [browse]
Author: Damien Neil
Date: 2026-09-16 09:58:08 -07:00
[release-branch.go1.27] net/http/internal/http2: avoid excessive work on initial window changes
Defend against a malicious peer sending many adjustments to the initial
flow control window.
The flow control window for a stream is:
initial_window + sum(window_updates) - sum(bytes_sent)
The initial window starts at 64k, but may be adjusted at any time
by a SETTINGS frame.
A decrease in the initial window might cause a stream's current
window to become negative, which is fine. (This happens when a
stream has already consumed some portion of its existing window.)
An increase in the initial window MUST NOT cause the window of
any stream to exceed the maximum of (2^31-1). RFC 9113 requires
us to check for this:
An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE
that causes any flow-control window to exceed the maximum size as
a connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
We enforced this by iterating over every active stream to adjust its
window and verify that the new window is not too large. While iterating
over streams is O(N), a malicious peer could send many small SETTINGS frames
and cause a large amount of CPU consumption when the number of open
streams is high.
The new implementation enforces the window less strictly, but performs
O(1) work in response to a change in the initial window.
Individual streams now maintain a delta from the initial window:
delta = sum(window_updates) - sum(bytes_sent)
The current stream window is computed on-demand by adding the
current initial window to the delta.
Overflow is detected lazily, when trying to write data for a stream
or when processing a WINDOW_UPDATE. This is technically speaking
a violation of RFC 9113's requirements, but it's a harmless one
and ensures we never do excessive work in reaction to a change
in the initial window.
Alternatives considered:
- Maintain a heap of streams, sorted by current window size.
Too complicated. Too much overhead. The juice is not worth the squeeze.
- Maintain a high-water mark for the stream delta, and only do an O(N)
iteration over all streams when the high-water mark indicates that
overflow might have happened. Avoids expensive processing in most
cases, but is vulnerable to a peer sending a rapid sequence of:
create stream
update stream window (updating the high-water mark)
reset stream
increase initial window to cause iteration (no violation)
decrease initial window
This scenario is more work than just a sequence of changes to the
initial window, and there are possibly ways to defend against it,
but lazy overflow detection is simpler and extremely robust.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
Fixes CVE-2026-78669
Fixes #81904
For #81742
Change-Id: I5667b01f81427141a0d873e2ec47052a6a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5921
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847031
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
clone the repository to get more history