commit 2ae494ef9fb90e0da0073c31800ba38870249994 [browse]
Author: Gopher Robot
Date: 2026-10-08 08:23:40 -07:00
[release-branch.go1.26] go1.26.9
Change-Id: Id12b30bb1c4f9e3e6a676fc04faf88dfd6d81021
Reviewed-on: https://go-review.googlesource.com/c/go/+/847127
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
commit 6e049521882c944afc1e519a83971ec421dc2974 [browse]
Author: Nicholas S. Husin
Date: 2026-09-30 18:49:55 -04:00
[release-branch.go1.26] net/http: bundled HTTP/2 vuln fixes
This CL is a bundle of several CLs. Description of bundled CLs are
copied verbatim below:
http2: avoid excessive work on initial window changes
This is the backport of the equivalent fix in std.
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
For #81903
For #81742
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
For #81743
For #81905
http2: prevent crash due to HPACK encoder race
This is a backport CL for the equivalent change in std.
Fixes CVE-2026-97032
For golang/go#81867
Fixes golang/go#81921
http2: apply header limits to Trailer headers too
This is a backport CL for the equivalent change in std.
Fixes CVE-2026-78659
For golang/go#81857
Fixes golang/go#81917
Change-Id: I2a1e2a566598abaee22221474d74dbac6a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6060
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847111
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
commit eb25b4e532c5a01f99ef860ec66743a8783f992b [browse]
Author: Damien Neil
Date: 2026-09-14 16:04:43 -07:00
[release-branch.go1.26] net/http: limit the size of range headers parsed in ServeContent
Set a limit on the number of ranges in a Range header,
avoiding excessive allocations/CPU when parsing a header
containing a large number of small ranges.
The limit is controlled by GODEBUG=httpservecontentmaxranges.
The default is 200 (same as Apache).
GODEBUG=httpservecontentmaxranges=0 disables the limit.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
Fixes CVE-2026-78667
For golang/go#81858
Fixes golang/go#81919
Change-Id: Id7df8059e2a406e3a401bb5cb767b4d16a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5560
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6201
Commit-Queue: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847110
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 be88124d06cecc37d12dddd62060cbe64bacb330 [browse]
Author: Damien Neil
Date: 2026-09-15 14:20:33 -07:00
[release-branch.go1.26] os: correct Root junction handling on Windows (avoid mkdir escape)
Avoid an escape from the root on Windows when the target of Root.Mkdir
or Root.MkdirAll is a dangling junction. This would incorrectly create
a new directory at the target of the junction, even when this is a
location outside of the root.
Also fix a more minor issue where various operations on a junction
would fail when the target name ended in a trailing slash. For example,
Root.Lstat("target/") would return ENOTDIR when "target" is a junction,
instead of following the junction or returning a path-escapes error.
Thanks to Daniele Ballarini for reporting this issue.
Fixes CVE-2026-56857
For golang/go#81739
Fixes golang/go#81897
Change-Id: If92a6b425ff33af6fb05c94b0d3d98e26a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5580
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6163
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847109
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
commit 087de1ff08ea620ac2f6ae26c939454cb793883a [browse]
Author: Damien Neil
Date: 2026-08-14 16:53:55 -07:00
[release-branch.go1.26] net/http: avoid server reuse of connection after CONNECT
When a server HTTP handler responds to an HTTP/1 CONNECT request
with a 2xx response and returns without taking ownership of (hijacking)
the connection, the server incorrectly continues to read requests
from the connection.
Since a 2xx response to a CONNECT converts the connection into
a tunnel, this can result in parser misalignment between the net/http
server and intermediate proxies, and a potential request smuggling
vector.
There are a number of problems in net/http's handling of CONNECT
requests. This CL is a minimal change to avoid exploitable misbehavior
in the server.
The HTTP/1 server now always closes a connection after handling a
CONNECT request, if the handler did not hijack the connection.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
Fixes CVE-2026-94439
For golang/go#81744
Fixes golang/go#81907
Change-Id: I260f23ca8c8fbe51abb2bdfef5afb2d96a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5641
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6162
Reviewed-on: https://go-review.googlesource.com/c/go/+/847108
Auto-Submit: Gopher Robot <gobot@golang.org>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
clone the repository to get more history