commit 8e10ef451a1b6a1e8861ced1154e1c3265bfa01b [browse]
Author: Gopher Robot
Date: 2025-10-13 14:05:31 -07:00

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

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

commit ca6a5545ba18844a97c88a90a385eb6335bb7526 [browse]
Author: Roland Shoemaker
Date: 2025-10-09 13:35:24 -07:00

[release-branch.go1.24] crypto/x509: rework fix for CVE-2025-58187

In CL 709854 we enabled strict validation for a number of properties of
domain names (and their constraints). This caused significant breakage,
since we didn't previously disallow the creation of certificates which
contained these malformed domains.

Rollback a number of the properties we enforced, making domainNameValid
only enforce the same properties that domainToReverseLabels does. Since
this also undoes some of the DoS protections our initial fix enabled,
this change also adds caching of constraints in isValid (which perhaps
is the fix we should've initially chosen).

Updates #75835
Updates #75828
Fixes #75860

Change-Id: Ie6ca6b4f30e9b8a143692b64757f7bbf4671ed0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/710735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 1cd71689f2ed8f07031a0cc58fc3586ca501839f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/710879
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>

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>