Roland Shoemaker [Wed, 7 Jun 2023 22:27:13 +0000 (15:27 -0700)]
[release-branch.go1.20] crypto/tls: restrict RSA keys in certificates to <= 8192 bits
Extremely large RSA keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.
Thanks to Mateusz Poliwczak for reporting this issue.
Updates #61460
Fixes #61580
Fixes CVE-2023-29409
Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1912161 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
(cherry picked from commit d865c715d92887361e4bd5596e19e513f27781b7)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1965747
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/514900
Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[release-branch.go1.20] cmd/asm, cmd/internal/obj: generate proper atomic ops for riscv64
Go's memory model closely follows the approach C++ concurrency memory
model (https://go.dev/ref/mem) and Go atomic "has the same semantics as C++'s
sequentially consistent atomics".
Meanwhile according to RISCV manual A.6 "Mappings from C/C++ primitives to RISC-V primitives".
C/C++ atomic operations (memory_order_acq_rel) should be map to "amo<op>.{w|d}.aqrl"
LR/SC (memory_order_acq_rel) should map to "lr.{w|d}.aq; <op>; sc.{w|d}.rl"
Damien Neil [Wed, 28 Jun 2023 20:20:08 +0000 (13:20 -0700)]
[release-branch.go1.20] net/http: validate Host header before sending
Verify that the Host header we send is valid.
Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops"
adding an X-Evil header to HTTP/1 requests.
Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to
header injection in the way HTTP/1 is, but x/net/http2 doesn't validate
the header and will go into a retry loop when the server rejects it.
CL 506995 adds the necessary validation to x/net/http2.
For #60374
Fixes #61076
For CVE-2023-29406
Change-Id: I05cb6866a9bead043101954dfded199258c6dd04
Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit 499458f7ca04087958987a33c2703c3ef03e27e2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/507357 Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Jelle van den Hooff [Thu, 22 Jun 2023 01:28:05 +0000 (18:28 -0700)]
[release-branch.go1.20] runtime: set raceignore to zero when starting a new goroutine
When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.
A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.
For #60934
Fixes #60949
Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 48dbb6227acf3ebc8ac21924567aa2b6d5064915)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505676 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Alex Brainman [Sat, 4 Mar 2023 03:35:35 +0000 (14:35 +1100)]
[release-branch.go1.20] runtime: allow for 5 more threads in TestWindowsStackMemory*
Original version of TestWindowsStackMemory did not consider sysmon and
other threads running during the test. Allow for 5 extra threads in this
test - this should cover any new threads in the future.
For #58570
Change-Id: I215790f9b94ff40a32ddd7aa54af715d1dc391c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/473415 Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit f6cbc1da05da141a78ee33954b52d17642c95130)
Reviewed-on: https://go-review.googlesource.com/c/go/+/506975
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Roland Shoemaker [Wed, 21 Jun 2023 21:43:05 +0000 (14:43 -0700)]
[release-branch.go1.20] crypto/x509: tolerate multiple matching chains in testVerify
Due to the semantics of roots, a root store may contain two valid roots
that have the same subject (but different SPKIs) at the asme time. As
such in testVerify it is possible that when we verify a certificate we
may get two chains that has the same stringified representation.
Rather than doing something fancy to include keys (which is just overly
complicated), tolerate multiple matches.
Updates #60925
Fixes #60947
Change-Id: I5f51f7635801762865a536bcb20ec75f217a36ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/505035 Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 20313660f5f3a87dfd9074c4061c521fa25fcd32)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505275
Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
[release-branch.go1.20] runtime: resolve checkdead panic by refining `startm` lock handling in caller context
This change addresses a `checkdead` panic caused by a race condition between
`sysmon->startm` and `checkdead` callers, due to prematurely releasing the
scheduler lock. The solution involves allowing a `startm` caller to acquire the
scheduler lock and call `startm` in this context. A new `lockheld` bool
argument is added to `startm`, which manages all lock and unlock calls within
the function. The`startIdle` function variable in `injectglist` is updated to
call `startm` with the lock held, ensuring proper lock handling in this
specific case. This refined lock handling resolves the observed race condition
issue.
For #59600.
Fixes #60760.
Change-Id: I11663a15536c10c773fc2fde291d959099aa71be
Reviewed-on: https://go-review.googlesource.com/c/go/+/487316 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
(cherry picked from commit ff059add10d71fe13239cf893c0cca113de1fc21)
Reviewed-on: https://go-review.googlesource.com/c/go/+/504395 Reviewed-by: Lucien Coffe <lucien.coffe@botify.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
[release-branch.go1.20] runtime: fallback to TEB arbitrary pointer when TLS slots are full
Note: This CL is cherry-picked from CL 486816 omitting the changes
in sys_windows_386.s, which don't apply to go1.20 release branch
because windows/386 started using the TEB TLS slot in go1.21 (CL 454675).
The Go runtime allocates the TLS slot in the TEB TLS slots instead of
using the TEB arbitrary pointer. See CL 431775 for more context.
The problem is that the TEB TLS slots array only has capacity for 64
indices, allocating more requires some complex logic that we don't
support yet.
Although the Go runtime only allocates one index, a Go DLL can be
loaded in a process with more than 64 TLS slots allocated,
in which case it abort.
This CL avoids aborting by falling back to the older behavior, that
is to use the TEB arbitrary pointer.
Fixes #60535
Updates #59213
Change-Id: I39c73286fe2da95aa9c5ec5657ee0979ecbec533
Reviewed-on: https://go-review.googlesource.com/c/go/+/486816 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 715d53c090ea02dbd73c301684ecbd09b476989e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/504475 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Cherry Mui [Thu, 15 Jun 2023 22:16:51 +0000 (18:16 -0400)]
[release-branch.go1.20] runtime: use 1-byte load for address checking in racecallatomic
In racecallatomic, we do a load before calling into TSAN, so if
the address is invalid we fault on the Go stack. We currently use
a 8-byte load instruction, regardless of the data size that the
atomic operation is performed on. So if, say, we are doing a
LoadUint32 at an address that is the last 4 bytes of a memory
mapping, we may fault unexpectedly. Do a 1-byte load instead.
(Ideally we should do a load with the right size, so we fault
correctly if we're given an unaligned address for a wide load
across a page boundary. Leave that for another CL.)
Fix AMD64, ARM64, and PPC64. The code already uses 1-byte load
on S390X.
Fixes #60845.
Updates #60825.
Change-Id: I3dee93eb08ba180c85e86a9d2e71b5b520e8dcf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/503937
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 1a7709d6af76c06d465c5e969b502fc206f8e687)
Reviewed-on: https://go-review.googlesource.com/c/go/+/503976
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Austin Clements <austin@google.com>
Ian Lance Taylor [Mon, 19 Jun 2023 22:35:50 +0000 (15:35 -0700)]
[release-branch.go1.20] net/mail: permit more characters in mail headers
We parse mail messages using net/textproto. For #53188, we tightened
up the bytes permitted by net/textproto to match RFC 7230.
However, this package uses RFC 5322 which is more permissive.
Restore the permisiveness we used to have, so that older code
continues to work.
For #58862
For #60332
Fixes #60874
Fixes #60875
Change-Id: I5437f5e18a756f6ca61c13c4d8ba727be73eff9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/504881
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Heschi Kreinick [Wed, 29 Mar 2023 17:13:19 +0000 (13:13 -0400)]
[release-branch.go1.20] cmd/go: fix tests for new builder environment
Fix two long tests that fail in the builders we're trying out:
- TestQueryImport was failing with:
open /nonexist-gopath/pkg/sumdb/sum.golang.org/latest: no such file or directory
which eventually turns out to be because it couldn't create
/nonexist-gopath because it wasn't running as root. The test already
uses a temporary GOPATH, but missed overriding a configuration
variable set at init time.
- test_flags fails if the working directory has /x/ in it, which it now
happens to.
Bryan C. Mills [Mon, 15 May 2023 15:49:56 +0000 (11:49 -0400)]
[release-branch.go1.20] cmd/cover: error out if a requested source file contains a newline
cmd/cover uses '//line' directives to map instrumented source files
back to the original source file and line numbers.
Line directives have no way to escape newline characters, so cmd/cover
must not be used with source file paths that contain such characters.
Updates #60516.
Updates #60167.
Change-Id: I6dc039392d59fc3a5a6121ef6ca97b0ab0da5288
Reviewed-on: https://go-review.googlesource.com/c/go/+/501577
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 3d78c735fc7d213e23383b9744297bd5251dc0e3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/501818
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Cuong Manh Le [Thu, 8 Jun 2023 02:58:22 +0000 (09:58 +0700)]
[release-branch.go1.20] cmd/compile: do not report division by error during typecheck
types2 have already errored about any spec-required overflows, and
division by zero. CL 469595 unintentionally fixed typecheck not to error
about overflows, but zero division is still be checked during tcArith.
This causes unsafe operations with variable size failed to compile,
instead of raising runtime error.
This CL also making change to typecheck.EvalConst, to stop evaluating
literal shifts or binary operators where {over,under}flows can happen.
For go1.21, typecheck.EvalConst is removed entirely, but that change is
too large to backport.
See discussion in CL 501735 for more details.
Fixes #60675
Change-Id: I7bea2821099556835c920713397f7c5d8a4025ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/501735
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/503855
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Bryan C. Mills [Sat, 20 May 2023 02:35:33 +0000 (22:35 -0400)]
[release-branch.go1.20] cmd/go: retain extra roots to disambiguate imports in 'go mod tidy'
We don't normally keep explicit requirements for test dependencies of
packages loaded from other modules when the required version is
already the selected version in the module graph. However, in some
cases we may need to keep an explicit requirement in order to make use
of lazy module loading to disambiguate an otherwise-ambiguous import.
Note that there is no Go version guard for this change: in the cases
where the behavior of 'go mod tidy' has changed, previous versions of
Go would produce go.mod files that break successive calls to
'go mod tidy'. Given that, I suspect that any existing user in the
wild affected by this bug either already has a workaround in place
using redundant import statements (in which case the change does not
affect them) or is running 'go mod tidy -e' to force past the error
(in which case a change in behavior to a non-error should not be
surprising).
Before, if a hash was exactly 66 bytes long, we weren't truncating it
for use with P-521, because the byte length was not overflowing.
However, the bit length could still overflow.
Fixes #60744
Updates #60741
Change-Id: I37a0ee210add0eb566e6dc1c141e83e992983eb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/502478
Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 886fba5871268c2dccba2675fea5aafacab59189)
Reviewed-on: https://go-review.googlesource.com/c/go/+/502915
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Michael Matloob [Mon, 12 Jun 2023 16:33:30 +0000 (12:33 -0400)]
[release-branch.go1.20] go/build: check for invalid import paths again
The go parser previously checked for invalid import paths, go/build,
seeing the parse error would put files with invalid import paths into
InvalidGoFiles. golang.org/cl/424855 removed that check from the
parser, which meant files with invalid import paths not have any parse
errors on them and not be put into InvalidGoFiles. Do a check for
invalid import paths in go/build soon after parsing so we can make
sure files with invalid import paths go into InvalidGoFiles.
This fixes an issue where the Go command assumed that if a file wasn't
invalid it had non empty import paths, leading to a panic.
Fixes #60754
Updates #60230
Updates #60686
Change-Id: I33c1dc9304649536834939cef7c689940236ee20
Reviewed-on: https://go-review.googlesource.com/c/go/+/502615 Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
(cherry picked from commit 962753b015407c69dd334578fd32a80aa7905c24)
Reviewed-on: https://go-review.googlesource.com/c/go/+/502697
Bryan C. Mills [Thu, 8 Jun 2023 21:55:55 +0000 (17:55 -0400)]
[release-branch.go1.20] cmd/go: omit checksums for go.mod files needed for go version lines more often in pre-1.21 modules
This updates the logic from CL 489075 to avoid trying to save extra
sums if they aren't already expected to be present
and cfg.BuildMod != "mod" (as in the case of "go list -m -u all" with
a go.mod file that specifies go < 1.21).
Change-Id: I3f5d14aee7d7195030e8872e42b1d97aa11d3582
Reviewed-on: https://go-review.googlesource.com/c/go/+/501298
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Directory or file paths containing newlines may cause tools (such as
cmd/cgo) that emit "//line" or "#line" -directives to write part of
the path into non-comment lines in generated source code. If those
lines contain valid Go code, it may be injected into the resulting
binary.
(Note that Go import paths and file paths within module zip files
already could not contain newlines.)
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Roland Shoemaker [Fri, 5 May 2023 20:10:34 +0000 (13:10 -0700)]
[release-branch.go1.20] cmd/go: enforce flags with non-optional arguments
Enforce that linker flags which expect arguments get them, otherwise it
may be possible to smuggle unexpected flags through as the linker can
consume what looks like a flag as an argument to a preceding flag (i.e.
"-Wl,-O -Wl,-R,-bad-flag" is interpreted as "-O=-R -bad-flag"). Also be
somewhat more restrictive in the general format of some flags.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Updates #60305
Fixes #60512
Fixes CVE-2023-29404
Change-Id: I5989f68d21a8851d8edd47f08550850524ee9180
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1876275 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 896779503cf754cbdac24b61d4cc953b50fe2dde)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1902226
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1904346 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501221
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Ian Lance Taylor [Thu, 4 May 2023 21:06:39 +0000 (14:06 -0700)]
[release-branch.go1.20] cmd/go,cmd/cgo: in _cgo_flags use one line per flag
The flags that we recorded in _cgo_flags did not use any quoting,
so a flag containing embedded spaces was mishandled.
Change the _cgo_flags format to put each flag on a separate line.
That is a simple format that does not require any quoting.
As far as I can tell only cmd/go uses _cgo_flags, and it is only
used for gccgo. If this patch doesn't cause any trouble, then
in the next release we can change to only using _cgo_flags for gccgo.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
Updates #60306
Fixes #60514
Fixes CVE-2023-29405
Change-Id: I36b6e188a44c80d7b9573efa577c386770bd2ba3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1875094 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com>
(cherry picked from commit bcdfcadd5612212089d958bc352a6f6c90742dcc)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1902228
Run-TryBot: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1904345 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501220
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.
Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() && getgid == getegid()).
Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
1. we check if the file descriptors 0, 1, and 2 are open, and if they
are not, we open them, pointing at /dev/null (or fail).
2. we force GOTRACKBACK=none, and generally prevent dumping of
trackbacks and registers when a program panics/aborts.
In the future we may add additional protections.
This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
Updates #60272
Fixes #60518
Fixes CVE-2023-29403
Change-Id: Icb620f3f8755791d51b02b5c07fb24f40e19cb80
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Russ Cox <rsc@google.com>
(cherry picked from commit 87065663ea6d89cd54f65a515d8f2ed0ef285c19)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1902232
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1904344 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501227
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
[release-branch.go1.20] cmd/go: save checksums for go.mod files needed for go version lines
When we load a package from a module, we need the go version line from
that module's go.mod file to know what language semantics to use for
the package. We need to save a checksum for the go.mod file even if
the module's requirements are pruned out of the module graph.
Previously, we were missing checksums for test dependencies of
packages in 'all' and packages passed to 'go get -t'.
This change preserves the existing bug for 'go mod tidy',
but fixes it for 'go get -t' and flags the missing checksum
with a clearer error in other cases.
Fixes #60001.
Updates #56222.
Change-Id: Icd6acce348907621ae0b02dbeac04fb180353dcf
(cherry picked from CL 489075 and CL 492741)
Reviewed-on: https://go-review.googlesource.com/c/go/+/493015
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ian Lance Taylor [Fri, 19 May 2023 22:09:58 +0000 (15:09 -0700)]
[release-branch.go1.20] net, os: net.Conn.File.Fd should return a blocking descriptor
Historically net.Conn.File.Fd has returned a descriptor in blocking mode.
That was broken by CL 495079, which changed the behavior for os.OpenFile
and os.NewFile without intending to affect net.Conn.File.Fd.
Use a hidden os entry point to preserve the historical behavior,
to ensure backward compatibility.
For #58408
For #60211
For #60217
Change-Id: I8d14b9296070ddd52bb8940cb88c6a8b2dc28c27
Reviewed-on: https://go-review.googlesource.com/c/go/+/496080
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
(cherry picked from commit b950cc8f11dc31cc9f6cfbed883818a7aa3abe94)
Reviewed-on: https://go-review.googlesource.com/c/go/+/496715
Ian Lance Taylor [Fri, 19 May 2023 04:13:03 +0000 (21:13 -0700)]
[release-branch.go1.20] runtime: change fcntl to return two values
Separate the result and the errno value, rather than assuming
that the result can never be negative.
Change-Id: Ib01a70a3d46285aa77e95371cdde74e1504e7c12
Reviewed-on: https://go-review.googlesource.com/c/go/+/496416
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/497116
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Clean up and consolidate on a single consistent definition of fcntl,
which takes three int32 arguments and returns either a positive result
or a negative errno value.
Change-Id: Id9505492712db4b0aab469c6bd15e4fce3c9ff6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495075
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/497115
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
When combining a byteswap and a load, the resulting combined op
must go in the load's block, not the byteswap's block, as the load
has a memory argument that might only be valid in its original block.
Fixes #59975
Change-Id: Icd84863ef3a9ca1fc22f2bb794a003f2808c746f
Reviewed-on: https://go-review.googlesource.com/c/go/+/492616
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Keith Randall <khr@google.com>
(cherry picked from commit 10141676d15665ed8a0255cfc5585ad50444f4ee)
Reviewed-on: https://go-review.googlesource.com/c/go/+/492696
Roland Shoemaker [Thu, 13 Apr 2023 21:01:50 +0000 (14:01 -0700)]
[release-branch.go1.20] html/template: emit filterFailsafe for empty unquoted attr value
An unquoted action used as an attribute value can result in unsafe
behavior if it is empty, as HTML normalization will result in unexpected
attributes, and may allow attribute injection. If executing a template
results in a empty unquoted attribute value, emit filterFailsafe
instead.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
For #59722
Fixes #59816
Fixes CVE-2023-29400
Change-Id: Ia38d1b536ae2b4af5323a6c6d861e3c057c2570a
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1826631 Reviewed-by: Julie Qiu <julieqiu@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1851494
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/491358 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Roland Shoemaker [Thu, 13 Apr 2023 22:40:44 +0000 (15:40 -0700)]
[release-branch.go1.20] html/template: disallow angle brackets in CSS values
Angle brackets should not appear in CSS contexts, as they may affect
token boundaries (such as closing a <style> tag, resulting in
injection). Instead emit filterFailsafe, matching the behavior for other
dangerous characters.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
For #59720
Fixes #59812
Fixes CVE-2023-24539
Change-Id: Iccc659c9a18415992b0c05c178792228e3a7bae4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1826636 Reviewed-by: Julie Qiu <julieqiu@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1851492
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/491336
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
When server and client have mismatch in curve preference, the server will
send HelloRetryRequest during TLSv1.3 PSK resumption. There was a bug
introduced by Go1.19.6 or later and Go1.20.1 or later, that makes the client
calculate the PSK binder hash incorrectly. Server will reject the TLS
handshake by sending alert: invalid PSK binder.
For #59424.
Fixes #59540.
Change-Id: I2ca8948474275740a36d991c057b62a13392dbb9
GitHub-Last-Rev: 1aad9bcf27f563449c1a7ed6d0dd1d247cc65713
GitHub-Pull-Request: golang/go#59425
Reviewed-on: https://go-review.googlesource.com/c/go/+/481955 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 2c70690451f1484607a9172a4c24f78ae832dcb0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/488055
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Matthew Dempsky [Wed, 12 Apr 2023 19:41:45 +0000 (12:41 -0700)]
[release-branch.go1.20] cmd/compile: fix reproducible build of aliased generic types
Due to a missing "&& !alias" check, the unified linker was treating
type aliases the same as defined types for the purpose of exporting
method bodies. The methods will get exported anyway alongside the
aliased type, so this mistake is normally harmless.
However, if multiple type aliases instantiated the same generic type
but with different type arguments, this could result in the
same (generic) method body being exported multiple times under
different symbol names. Further, because bodies aren't expected to be
exported multiple times, we were sorting them simply based on index.
And consequently, the sort wasn't total and is sensitive to the map
iteration order used while ranging over linker.bodies.
The fix is simply to add the missing "&& !alias" check, so that we
don't end up with duplicate bodies in the first place.
Thanks rsc@ for providing a minimal repro case.
Fixes #59585.
Change-Id: Iaa55968cc7110b601e2f0f9b620901c2d55f7014
Reviewed-on: https://go-review.googlesource.com/c/go/+/484155 Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit f58c6cccc44752146aabcd50a30865e34817a4b4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/484160 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
CL 440035 added rewrite rules to simplify "costly" LEA
instructions, but the types in the rewrites were wrong and
the code would go bad if the wrong-typed register was spilled.
CL 482536 attempted to fix this by correcting the type in the
rewrite, but that "fix" broke something on windows-amd64-race.
Instead / for-now, remove the offending rewrite rules.
Updates #21735.
Updates #59432.
Fixes #59468.
Change-Id: I0497c42db414f2055e1378e0a53e2bceee9cd5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/482820
Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 6a97a60b4b80dfa9db91200c054d734e18dda115)
Reviewed-on: https://go-review.googlesource.com/c/go/+/482164
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Keith Randall [Sat, 1 Apr 2023 17:33:26 +0000 (10:33 -0700)]
[release-branch.go1.20] cmd/compile: use correct type for byteswaps on multi-byte stores
Use the type of the store for the byteswap, not the type of the
store's value argument.
Normally when we're storing a 16-bit value, the value being stored is
also typed as 16 bits. But sometimes it is typed as something smaller,
usually because it is the result of an upcast from a smaller value,
and that upcast needs no instructions.
If the type of the store's arg is thinner than the type being stored,
and the byteswap'd value uses that thinner type, and the byteswap'd
value needs to be spilled & restored, that spill/restore happens using
the thinner type, which causes us to lose some of the top bits of the
value.
Fixes #59374
Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit b3bc8620f89153fddc1a30ee17c1d93654ed4314)
Reviewed-on: https://go-review.googlesource.com/c/go/+/483176
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Ian Lance Taylor [Wed, 22 Mar 2023 20:17:58 +0000 (13:17 -0700)]
[release-branch.go1.20] syscall: restore original NOFILE rlimit in child process
If we increased the NOFILE rlimit when starting the program,
restore the original rlimit when forking a child process.
In CL 393354 the os package was changed to raise the open file rlimit
at program start. That code is not inherently tied to the os package.
This CL moves it into the syscall package.
This is a backport of CLs 476096 and 476097 from trunk.
For #46279
Fixes #59064
Change-Id: Ib813de896de0a5d28fa2b29afdf414a89fbe7b2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/478659
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Keith Randall [Thu, 30 Mar 2023 16:52:39 +0000 (09:52 -0700)]
[release-branch.go1.20] crypto/subtle: don't cast to *uintptr when word size is 0
Casting to a *uintptr is not ok if there isn't at least 8 bytes of
data backing that pointer (on 64-bit archs).
So although we end up making a slice of 0 length with that pointer,
the cast itself doesn't know that.
Instead, bail early if the result is going to be 0 length.
Fixes #59336
Change-Id: Id3c0e09d341d838835c0382cccfb0f71dc3dc7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/480575
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 297cf6dd31bd99fc4ccda320aa3d4faf290ab278)
Reviewed-on: https://go-review.googlesource.com/c/go/+/481238 Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Michael Anthony Knyszek [Tue, 4 Apr 2023 22:07:09 +0000 (22:07 +0000)]
[release-branch.go1.20] html/template,mime/multipart: document new GODEBUG settings
This change documents the new GODEBUG settings introduced for
html/template and mime/multipart, released with Go 1.19.8 and Go 1.20.3
as part of a security fix.
Updates #59153.
For #59270.
Updates #59234.
For #59272.
Change-Id: I25f4d8245da3301dccccfb44da8ff1a5985392a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/482555
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Roland Shoemaker [Mon, 20 Mar 2023 18:01:13 +0000 (11:01 -0700)]
[release-branch.go1.20] html/template: disallow actions in JS template literals
ECMAScript 6 introduced template literals[0][1] which are delimited with
backticks. These need to be escaped in a similar fashion to the
delimiters for other string literals. Additionally template literals can
contain special syntax for string interpolation.
There is no clear way to allow safe insertion of actions within JS
template literals, as handling (JS) string interpolation inside of these
literals is rather complex. As such we've chosen to simply disallow
template actions within these template literals.
A new error code is added for this parsing failure case, errJsTmplLit,
but it is unexported as it is not backwards compatible with other minor
release versions to introduce an API change in a minor release. We will
export this code in the next major release.
The previous behavior (with the cavet that backticks are now escaped
properly) can be re-enabled with GODEBUG=jstmpllitinterp=1.
This change subsumes CL471455.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting
this issue.
The parsed forms of MIME headers and multipart forms can consume
substantially more memory than the size of the input data.
A malicious input containing a very large number of headers or
form parts can cause excessively large memory allocations.
Set limits on the size of MIME data:
Reader.NextPart and Reader.NextRawPart limit the the number
of headers in a part to 10000.
Reader.ReadForm limits the total number of headers in all
FileHeaders to 10000.
Both of these limits may be set with with
GODEBUG=multipartmaxheaders=<values>.
Reader.ReadForm limits the number of parts in a form to 1000.
This limit may be set with GODEBUG=multipartmaxparts=<value>.
Thanks for Jakob Ackermann (@das7pad) for reporting this issue.
For CVE-2023-24536
For #59153
For #59270
Change-Id: I36ddceead7f8292c327286fd8694e6113d3b4977
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802455
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802608
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/481991
Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Damien Neil [Thu, 16 Mar 2023 21:18:04 +0000 (14:18 -0700)]
[release-branch.go1.20] mime/multipart: avoid excessive copy buffer allocations in ReadForm
When copying form data to disk with io.Copy,
allocate only one copy buffer and reuse it rather than
creating two buffers per file (one from io.multiReader.WriteTo,
and a second one from os.File.ReadFrom).
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
For CVE-2023-24536
For #59153
For #59270
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802453
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com>
Change-Id: I44ef17c4b4964cdac2858317275594194801fee3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802398
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/481989
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Damien Neil [Fri, 10 Mar 2023 22:21:05 +0000 (14:21 -0800)]
[release-branch.go1.20] net/textproto: avoid overpredicting the number of MIME header keys
A parsed MIME header is a map[string][]string. In the common case,
a header contains many one-element []string slices. To avoid
allocating a separate slice for each key, ReadMIMEHeader looks
ahead in the input to predict the number of keys that will be
parsed, and allocates a single []string of that length.
The individual slices are then allocated out of the larger one.
The prediction of the number of header keys was done by counting
newlines in the input buffer, which does not take into account
header continuation lines (where a header key/value spans multiple
lines) or the end of the header block and the start of the body.
This could lead to a substantial amount of overallocation, for
example when the body consists of nothing but a large block of
newlines.
Fix header key count prediction to take into account the end of
the headers (indicated by a blank line) and continuation lines
(starting with whitespace).
Thanks to Jakob Ackermann (@das7pad) for reporting this issue.
Fixes CVE-2023-24534
For #58975
Fixes #59268
Change-Id: I0591593e67b6fdba22a32dcc3334fad797727f5c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452
Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802397
Run-TryBot: Roland Shoemaker <bracewell@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/481988
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Lynn Boger [Mon, 27 Mar 2023 13:26:59 +0000 (08:26 -0500)]
[release-branch.go1.20] cmd/internal/obj/ppc64: fix incorrect base reg causing segv
This fixes a segv that was reported due to building minio. The
problem occurred because of an incorrect selection of the
base register, which was introduced by CL 306369.
Keith Randall [Tue, 28 Mar 2023 17:19:21 +0000 (10:19 -0700)]
[release-branch.go1.20] cmd/compile: don't assume pointer of a slice is non-nil
unsafe.SliceData can return pointers which are nil. That function gets
lowered to the SSA OpSlicePtr, which the compiler assumes is non-nil.
This used to be the case as OpSlicePtr was only used in situations
where the bounds check already passed. But with unsafe.SliceData that
is no longer the case.
There are situations where we know it is nil. Use Bounded() to
indicate that.
I looked through all the uses of OSPTR and added SetBounded where it
made sense. Most OSPTR results are passed directly to runtime calls
(e.g. memmove), so even if we know they are non-nil that info isn't
helpful.
Fixes #59296
Change-Id: I437a15330db48e0082acfb1f89caf8c56723fc51
Reviewed-on: https://go-review.googlesource.com/c/go/+/479896 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
(cherry picked from commit b899641ecea7d07c997282e985beb295c31d1097)
Reviewed-on: https://go-review.googlesource.com/c/go/+/479899
Run-TryBot: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Cuong Manh Le [Fri, 17 Mar 2023 17:53:07 +0000 (00:53 +0700)]
[release-branch.go1.20] cmd/compile: re-compile instantiated generic methods in linkshared mode
For G[T] that was seen and compiled in imported package, it is not added
to typecheck.Target.Decls, prevent wasting compile time re-creating
DUPOKS symbols. However, the linker do not support a type symbol
referencing a method symbol across DSO boundary. That causes unreachable
sym error when building under -linkshared mode.
To fix it, always re-compile generic methods in linkshared mode.
Fixes #59236
Change-Id: I894b417cfe8234ae1fe809cc975889345df22cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/477375
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/479355
Geon Kim [Sat, 11 Mar 2023 00:57:57 +0000 (00:57 +0000)]
[release-branch.go1.20] time: fix timezone lookup logic for non-DST zones
This change fixes time.LoadLocationFromTZData and time.Location.lookup logic if the given time is after the last transition and the extend string doesn't have the DST rule.
For #58682
Fixes #59075
Change-Id: Ie34a6d658d14c2b33098b29ab83c041ef0d34266
GitHub-Last-Rev: f6681eb44c0ea0772004e56eb68fcbd9023d971e
GitHub-Pull-Request: golang/go#58684
Reviewed-on: https://go-review.googlesource.com/c/go/+/471020 Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
(cherry picked from commit 90dde5dec1126ddf2236730ec57511ced56a512d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/478658 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Than McIntosh [Mon, 13 Mar 2023 16:02:36 +0000 (12:02 -0400)]
[release-branch.go1.20] cmd/link/internal/arm: fix off-by-1 in trampoline reachability computation
Tweak the code in trampoline generation that determines if a given
call branch will reach, changing the lower limit guard from "x <
-0x800000" to "x <= -0x800000". This is to resolve linking failures
when the computed displacement is exactly -0x800000, which results in
errors of the form
.../ld.gold: internal error in arm_branch_common, at ../../gold/arm.cc:4079
when using the Gold linker, and
...:(.text+0x...): relocation truncated to fit: R_ARM_CALL against `runtime.morestack_noctxt'
when using the bfd linker.
Fixes #59059.
Updates #59034.
Updates #58425.
Change-Id: I8a76986b38727df1b961654824c2af23f06b9fcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/475957
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit f26bf203ac67fd917f2eb992baa1cb2d01edf3c8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/476936
Than McIntosh [Fri, 10 Mar 2023 15:29:38 +0000 (10:29 -0500)]
[release-branch.go1.20] cmd/go,cmd/link: prefer external linking when strange cgo flags seen
This patch changes the Go command to examine the set of compiler
flags feeding into the C compiler when packages that use cgo are built.
If any of a specific set of strange/dangerous flags are in use,
then the Go command generates a token file ("preferlinkext") and
embeds it into the compiled package's archive.
When the Go linker reads the archives of the packages feeding into the
link and detects a "preferlinkext" token, it will then use external
linking for the program by default (although this default can be
overridden with an explicit "-linkmode" flag).
The intent here is to avoid having to teach the Go linker's host object
reader to grok/understand the various odd symbols/sections/types that
can result from boutique flag use, but rather to just boot the objects
in question over to the C linker instead.
Cherry Mui [Wed, 8 Mar 2023 21:38:32 +0000 (16:38 -0500)]
[release-branch.go1.20] cmd/link: use label symbols for Duff's devices on darwin/arm64
On darwin, the external linker generally supports CALL relocations
with addend. One exception is that for a very large binary when it
decides to insert a trampoline, instead of applying the addend to
the call target (in the trampoline), it applies the addend to the
CALL instruction in the caller, i.e. generating a call to
trampoline+addend, which is not the correct address and usually
points to unreloated functions.
To work around this, we use label symbols so the CALL is targeting
a label symbol without addend. To make things simple we always use
label symbols for CALLs with addend (in external linking mode on
darwin/arm64), even for small binaries.
Updates #58935.
Fixes #58954.
Change-Id: I38aed6b62a0496c277c589b5accbbef6aace8dd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/474620
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 7dbd6de7d45da622e532e149de616e159286e1d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/475175
Bryan C. Mills [Tue, 7 Mar 2023 20:12:29 +0000 (15:12 -0500)]
[release-branch.go1.20] cmd/go: avoid running slow tests on non-longtest builders
Also annotate calls to tooSlow with specific reasons.
This will somewhat reduce test coverage on the 'darwin' builders until
we have darwin 'longtest' builders (#35678,#49055), but still seems
worthwhile to avoid alert fatigue from tests that really shouldn't be
running in the short configurations.
Updates #58918.
Updates #58919.
Fixes #58938.
Change-Id: I0000f0084b262beeec3eca3e9b8a45d61fab4313
Reviewed-on: https://go-review.googlesource.com/c/go/+/474137 Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 9f532dd0de78af91694a2d7e5e3c45b2978d1062)
Reviewed-on: https://go-review.googlesource.com/c/go/+/474580
When calling a c library function, you discover that an error has
occurred, typically by looking at the return value of the function. Only
after that can you use errno to figure out the cause of the error.
Nothing about cgo changes that story -- you still have to look at the
result before checking the error that represents errno. If not you can
get false errors if the function happens to leak a non-zero errno.
The assertion here was to make sure the newly constructed and
typechecked expression selected the same receiver-qualified method,
but in the case of anonymous receiver types we can actually end up
with separate types.Field instances corresponding to each types.Type
instance. In that case, the assertion spuriously failed.
The fix here is to relax and assertion and just compare the method's
name and type (including receiver type).
Fixes #58776.
Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886
Reviewed-on: https://go-review.googlesource.com/c/go/+/471676
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 37a2004b431df6cdd3260cbfe2ddb7673e94b9ef)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472620
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Roland Shoemaker [Tue, 28 Feb 2023 21:23:43 +0000 (13:23 -0800)]
[release-branch.go1.20] crypto/x509: fix system root tests + darwin intermediate handling
On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.
Updates #58791
Fixes #58811
Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
(cherry picked from commit bb8f9a6ae66d742cb67b4ad444179905a537de00)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472616
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This test is flaky, apparently due to a typo'd operator in CL 21447
that causes it to compare “same port OR IP” instead of
“same port AND IP”.
If we merely fixed the comparison, the test would hopefully stop being
flaky itself, but we would still be left with another problem:
repeatedly dialing a port that we believe to be unused can interfere
with other tests, which may open the previously-unused port and then
attempt a single Dial and expect it to succeed. Arbitrary other Dial
calls for that port may cause the wrong connection to be accepted,
leading to spurious test failures.
Moreover, the test can be extremely expensive for the amount of data
we hope to get from it, depending on the system's port-reuse
algorithms and dial implementations. It is already scaled back by up
to 1000x on a huge number of platforms due to latency, and may even be
ineffective on those platforms because of the arbitrary 1ms Dial
timeout. And the incremental value from it is quite low, too: it tests
the workaround for what is arguably a bug in the Linux kernel, which
ought to be fixed (and tested) upstream instead of worked around in
every open-source project that dials local ports.
Instead of trying to deflake this test, let's just get rid of it.
Updates #18290.
Fixes #58717.
Change-Id: I8a58b93d67916a33741c9ab29ef99c49c46b32c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/460657
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
(cherry picked from commit e08642cae18460778ba3f7808c91cbf6d9ee9f67)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471155 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Kir Kolyshkin [Thu, 16 Feb 2023 00:47:40 +0000 (16:47 -0800)]
[release-branch.go1.20] syscall: Faccessat: check for CAP_DAC_OVERRIDE on Linux
CL 416115 added using faccessat2(2) from syscall.Faccessat on Linux
(which is the only true way to implement AT_EACCESS flag handing),
if available. If not available, it uses some heuristics to mimic the
kernel behavior, mostly taken from glibc (see CL 126415).
Next, CL 414824 added using the above call (via unix.Eaccess) to
exec.LookPath in order to check if the binary can really be executed.
As a result, in a very specific scenario, described below,
syscall.Faccessat (and thus exec.LookPath) mistakenly tells that the
binary can not be executed, while in reality it can be. This makes
this bug a regression in Go 1.20.
This scenario involves all these conditions:
- no faccessat2 support available (i.e. either Linux kernel < 5.8,
or a seccomp set up to disable faccessat2);
- the current user is not root (i.e. geteuid() != 0);
- CAP_DAC_OVERRIDE capability is set for the current process;
- the file to be executed does not have executable permission
bit set for either the current EUID or EGID;
- the file to be executed have at least one executable bit set.
Unfortunately, this set of conditions was observed in the wild -- a
container run as a non-root user with the binary file owned by root with
executable permission set for a user only [1]. Essentially it means it
is not as rare as it may seem.
Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the
checks, so execve(2) and friends work the same was as for root user,
i.e. if at least one executable bit it set, the permission to execute
is granted (see generic_permission() function in the Linux kernel).
Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel
behavior for permission checks.
Change-Id: I82a7e757ab3fd3d0193690a65c3b48fee46ff067
Reviewed-on: https://go-review.googlesource.com/c/go/+/468735 Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit 031401a7905a38498fc399fc10cd0c1e885f7fc9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/469956
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Roland Shoemaker [Tue, 31 Jan 2023 17:14:16 +0000 (09:14 -0800)]
[release-branch.go1.20] crypto/ecdh: explicitly reject mismatched curves in ECDH
Return an explicit error when PrivateKey.ECDH is called with a PublicKey
which uses a different Curve. Also document this requirement, even
though it is perhaps obvious.
Updates #58131.
Fixes #58498.
Change-Id: I739181a3f1283bed14fb5ee7eb78658b854d28d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/464335 Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 67d8916d551d22f5376e0be71d3922c9d63eaa6a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471602 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Matthew Dempsky [Tue, 14 Feb 2023 23:13:50 +0000 (15:13 -0800)]
[release-branch.go1.20] cmd/compile/internal/noder: correct positions for synthetic closures
When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.
However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.
go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.
This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.
Updates #54625.
Fixes #58531.
Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 873c14cec730ee278848f7cc58d2b4d89ab52288)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471677
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Than McIntosh [Fri, 17 Feb 2023 19:51:05 +0000 (14:51 -0500)]
[release-branch.go1.20] cmd/link: better fix for arm32 trampgen problem with duff routines
This patch provides a fix for a problem linking large arm32 binaries
with external linking, specifically R_CALLARM relocations against
runtime.duff* routines being flagged by the external linker as not
reaching.
What appears to be happening in the bug in question is that the Go
linker and the external linker are using slightly different recipes to
decide whether a given R_CALLARM relocation will "fit" (e.g. will not
require a trampoline). The Go linker is taking into account the addend
on the call reloc (which for calls to runtime.duffcopy or
runtime.duffzero is nonzero), whereas the external linker appears to
be ignoring the addend.
Let's say that the distance between ABC (start address of
runtime.duffcopy) and XYZ (start of MyFunc) is just over the
architected 24-bit maximum displacement for an R_CALLARM (let's say
that ABC-XYZ is just over the architected limit by some small value,
say 36). Because we're calling into runtime.duffcopy at offset 848,
however, the relocation does in fact fit, but if the external linker
isn't taking into account the addend (assuming that all calls target
the first instruction of the called routine), then we'll get a
"doesn't fit" error from the linker.
To work around this problem, revise the ARM trampoline generation code
in the Go linker that computes the trampoline threshold to ignore the
addend on R_CALLARM relocations, so as to harmonize the two linkers.
Fixes #58503.
Updates #58428.
Updates #58425.
Change-Id: I56e580c05b7b47bbe8edf5532a1770bbd700fbe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/469275
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
(cherry picked from commit 0b5affb193ed559f2cb646e0324827f261e2e767)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471597
Unlike the rest of nistec, the P-256 assembly doesn't use complete
addition formulas, meaning that p256PointAdd[Affine]Asm won't return the
correct value if the two inputs are equal.
This was (undocumentedly) ignored in the scalar multiplication loops
because as long as the input point is not the identity and the scalar is
lower than the order of the group, the addition inputs can't be the same.
As part of the math/big rewrite, we went however from always reducing
the scalar to only checking its length, under the incorrect assumption
that the scalar multiplication loop didn't require reduction.
Added a reduction, and while at it added it in P256OrdInverse, too, to
enforce a universal reduction invariant on p256OrdElement values.
Note that if the input point is the infinity, the code currently still
relies on undefined behavior, but that's easily tested to behave
acceptably, and will be addressed in a future CL.
Updates #58647
Fixes #58720
Fixes CVE-2023-24532
(Filed with the "safe APIs like complete addition formulas are good" dept.)
Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/471255
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 203e59ad41bd288e1d92b6f617c2f55e70d3c8e3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471695 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Than McIntosh [Wed, 8 Feb 2023 20:06:08 +0000 (15:06 -0500)]
[release-branch.go1.20] cmd/internal/cov: fix misuse of bufio.Reader.Read in read helper
Fix a misuse of bufio.Reader.Read in the helper class
cmd/internal/cov.MReader; the MReader method in question should have
been using io.ReadFull (passing the bufio.Reader) instead of directly
calling Read.
Using the Read method instead of io.ReadFull will result in a "short"
read when processing a specific subset of counter data files, e.g.
those that are short enough to not trigger the mmap-based scheme we
use for larger files, but also with a large args section (something
large enough to exceed the default 4k buffer size used by
bufio.Reader).
Along the way, add some additional defered Close() calls for files
opened by the CovDataReader.visitPod, to enure we don't leave any open
file descriptor following a call to CovDataReader.Visit.
Fixes #58427.
Updates #58411.
Change-Id: Iea48dc25c0081be1ade29f3a633df02a681fd941
Reviewed-on: https://go-review.googlesource.com/c/go/+/466677
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit a7fe9ada10c02a7ea61b2909ef7db151d290073f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/468536 Reviewed-by: Cherry Mui <cherryyz@google.com>
Michael Anthony Knyszek [Wed, 4 Jan 2023 05:20:58 +0000 (05:20 +0000)]
[release-branch.go1.20] runtime: check for overflow in sweep assist
The sweep assist computation is intentionally racy for performance,
since the specifics of sweep assist aren't super sensitive to error.
However, if overflow occurs when computing the live heap delta, we can
end up with a massive sweep target that causes the sweep assist to sweep
until sweep termination, causing severe latency issues. In fact, because
heapLive doesn't always increase monotonically then anything that
flushes mcaches will cause _all_ allocating goroutines to inevitably get
stuck in sweeping.
Consider the following scenario:
1. SetGCPercent is called, updating sweepHeapLiveBasis to heapLive.
2. Very shortly after, ReadMemStats is called, flushing mcaches and
decreasing heapLive below the value sweepHeapLiveBasis was set to.
3. Every allocating goroutine goes to refill its mcache, calls into
deductSweepCredit for sweep assist, and gets stuck sweeping until
the sweep phase ends.
Fix this by just checking for overflow in the delta live heap calculation
and if it would overflow, pick a small delta live heap. This probably
means that no sweeping will happen at all, but that's OK. This is a
transient state and the runtime will recover as soon as heapLive
increases again.
Note that deductSweepCredit doesn't check overflow on other operations
but that's OK: those operations are signed and extremely unlikely to
overflow. The subtraction targeted by this CL is only a problem because
it's unsigned. An alternative fix would be to make the operation signed,
but being explicit about the overflow situation seems worthwhile.
For #57523.
Fixes #58536.
Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215
Reviewed-on: https://go-review.googlesource.com/c/go/+/468375 Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Update golang.org/x/net to the tip of internal-branch.go1.20-vendor to
include CL 468336.
The contents of that CL were already merged into this branch in CL
468122, so this CL just brings go.mod back in line to matching the
actual vendored content.
For #58356
For #57855
Change-Id: I6ee9483077630c11c725927f38f6b69a784106db
Reviewed-on: https://go-review.googlesource.com/c/go/+/468302
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>