commit 3a666bca00d7fb30d55e252131ea2cf2006dc3a3 [browse]
Author: Gopher Robot
Date: 2025-10-07 11:10:58 -07:00

[release-branch.go1.24] go1.24.8

Change-Id: Ib7865e22255a979da9552ffd35145bb9dd39b53f
Reviewed-on: https://go-review.googlesource.com/c/go/+/709896
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>

commit 613e746327381d820759ebea6ce722720b343556 [browse]
Author: Damien Neil
Date: 2025-09-11 13:32:10 -07:00

[release-branch.go1.24] archive/tar: set a limit on the size of GNU sparse file 1.0 regions

Sparse files in tar archives contain only the non-zero components
of the file. There are several different encodings for sparse
files. When reading GNU tar pax 1.0 sparse files, archive/tar did
not set a limit on the size of the sparse region data. A malicious
archive containing a large number of sparse blocks could cause
archive/tar to read an unbounded amount of data from the archive
into memory.

Since a malicious input can be highly compressable, a small
compressed input could cause very large allocations.

Cap the size of the sparse block data to the same limit used
for PAX headers (1 MiB).

Thanks to Harshit Gupta (Mr HAX) (https://www.linkedin.com/in/iam-harshit-gupta/)
for reporting this issue.

Fixes CVE-2025-58183
For #75677
Fixes #75710

Change-Id: I70b907b584a7b8676df8a149a1db728ae681a770
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2800
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2967
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709843
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>

commit 74d4d836b91318a8764b94bc2b4b66ff599eb5f2 [browse]
Author: Roland Shoemaker
Date: 2025-09-30 11:16:56 -07:00

[release-branch.go1.24] encoding/pem: make Decode complexity linear

Because Decode scanned the input first for the first BEGIN line, and
then the first END line, the complexity of Decode is quadratic. If the
input contained a large number of BEGINs and then a single END right at
the end of the input, we would find the first BEGIN, and then scan the
entire input for the END, and fail to parse the block, so move onto the
next BEGIN, scan the entire input for the END, etc.

Instead, look for the first END in the input, and then the first BEGIN
that precedes the found END. We then process the bytes between the BEGIN
and END, and move onto the bytes after the END for further processing.
This gives us linear complexity.

Fixes CVE-2025-61723
For #75676
Fixes #75708

Change-Id: I813c4f63e78bca4054226c53e13865c781564ccf
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2921
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2986
Reviewed-on: https://go-review.googlesource.com/c/go/+/709842
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>

commit 5c3d61c886f7ecfce9a6d6d3c97e6d5a8afb17d1 [browse]
Author: Nicholas Husin
Date: 2025-09-03 09:30:56 -04:00

[release-branch.go1.24] encoding/asn1: prevent memory exhaustion when parsing using internal/saferio

Within parseSequenceOf, reflect.MakeSlice is being used to pre-allocate
a slice that is needed in order to fully validate the given DER payload.
The size of the slice allocated are also multiple times larger than the
input DER:

- When using asn1.Unmarshal directly, the allocated slice is ~28x
  larger.
- When passing in DER using x509.ParseCertificateRequest, the allocated
  slice is ~48x larger.
- When passing in DER using ocsp.ParseResponse, the allocated slice is
  ~137x larger.

As a result, a malicious actor can craft a big empty DER payload,
resulting in an unnecessary large allocation of memories. This can be a
way to cause memory exhaustion.

To prevent this, we now use SliceCapWithSize within internal/saferio to
enforce a memory allocation cap.

Thanks to Jakub Ciolek for reporting this issue.

For #75671
Fixes #75704
Fixes CVE-2025-58185

Change-Id: Id50e76187eda43f594be75e516b9ca1d2ae6f428
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2700
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2984
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709841
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>

commit c6b04dd33b0215f5deb83724661921842bf67607 [browse]
Author: Nicholas Husin
Date: 2025-09-30 14:02:38 -04:00

[release-branch.go1.24] net/http: add httpcookiemaxnum GODEBUG option to limit number of cookies parsed

When handling HTTP headers, net/http does not currently limit the number
of cookies that can be parsed. The only limitation that exists is for
the size of the entire HTTP header, which is controlled by
MaxHeaderBytes (defaults to 1 MB).

Unfortunately, this allows a malicious actor to send HTTP headers which
contain a massive amount of small cookies, such that as much cookies as
possible can be fitted within the MaxHeaderBytes limitation. Internally,
this causes us to allocate a massive number of Cookie struct.

For example, a 1 MB HTTP header with cookies that repeats "a=;" will
cause an allocation of ~66 MB in the heap. This can serve as a way for
malicious actors to induce memory exhaustion.

To fix this, we will now limit the number of cookies we are willing to
parse to 3000 by default. This behavior can be changed by setting a new
GODEBUG option: GODEBUG=httpcookiemaxnum. httpcookiemaxnum can be set to
allow a higher or lower cookie limit. Setting it to 0 will also allow an
infinite number of cookies to be parsed.

Thanks to jub0bs for reporting this issue.

For #75672
Fixes #75706
Fixes CVE-2025-58186

Change-Id: Ied58b3bc8acf5d11c880f881f36ecbf1d5d52622
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2720
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2983
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709840
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
clone the repository to get more history