go, branch go1.20.6

[release-branch.go1.20] go1.20.6

2023-07-11T15:58:20Z

Change-Id: I9dc89e8bca8cd6262f85be1266c53f53ab8c55a8 Reviewed-on: https://go-review.googlesource.com/c/go/+/508838 Reviewed-by: Cherry Mui Reviewed-by: Joedian Reid TryBot-Result: Gopher Robot Run-TryBot: Gopher Robot Auto-Submit: Gopher Robot

[release-branch.go1.20] net/http: validate Host header before sending

2023-07-06T19:41:17Z

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 TryBot-Result: Gopher Robot Run-TryBot: Damien Neil (cherry picked from commit 499458f7ca04087958987a33c2703c3ef03e27e2) Reviewed-on: https://go-review.googlesource.com/c/go/+/507357 Reviewed-by: Damien Neil Run-TryBot: Tatiana Bradley Reviewed-by: Roland Shoemaker

[release-branch.go1.20] runtime: set raceignore to zero when starting a new goroutine

2023-06-29T15:53:20Z

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 Reviewed-by: Michael Knyszek TryBot-Result: Gopher Robot Run-TryBot: Michael Knyszek (cherry picked from commit 48dbb6227acf3ebc8ac21924567aa2b6d5064915) Reviewed-on: https://go-review.googlesource.com/c/go/+/505676 Reviewed-by: Keith Randall Reviewed-by: Keith Randall

[release-branch.go1.20] runtime: allow for 5 more threads in TestWindowsStackMemory*

2023-06-28T20:21:58Z

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 Run-TryBot: Alex Brainman TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui (cherry picked from commit f6cbc1da05da141a78ee33954b52d17642c95130) Reviewed-on: https://go-review.googlesource.com/c/go/+/506975 Run-TryBot: Michael Knyszek Auto-Submit: Michael Knyszek

[release-branch.go1.20] cmd/go: skip TestScript/gccgo_link_ldflags on aix/ppc64

2023-06-24T02:06:39Z

The gccgo on the builder is not updated to support runtime/cgo For #60306. For #60514. Change-Id: If0fb1ccdf589cc9741f6a065bacfa4f06e64ec15 Reviewed-on: https://go-review.googlesource.com/c/go/+/501435 Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot Run-TryBot: Cuong Manh Le Reviewed-by: Benny Siegert Auto-Submit: Cuong Manh Le (cherry picked from commit 688d75b14fd7646d66c18825f22f0a67e9fafd9e) Reviewed-on: https://go-review.googlesource.com/c/go/+/505595 Reviewed-by: Dmitri Shuralyov Auto-Submit: Dmitri Shuralyov Reviewed-by: Than McIntosh Run-TryBot: Dmitri Shuralyov

[release-branch.go1.20] crypto/x509: tolerate multiple matching chains in testVerify

2023-06-22T18:46:41Z

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 Run-TryBot: Roland Shoemaker Auto-Submit: Roland Shoemaker TryBot-Result: Gopher Robot (cherry picked from commit 20313660f5f3a87dfd9074c4061c521fa25fcd32) Reviewed-on: https://go-review.googlesource.com/c/go/+/505275 Run-TryBot: Heschi Kreinick Reviewed-by: Roland Shoemaker Auto-Submit: Heschi Kreinick

[release-branch.go1.20] cmd/go/internal/test: don't wait for previous test actions when interrupted

2023-06-22T15:41:22Z

Fixes #60849. Updates #60203. Change-Id: I59a3320ede1eb3cf4443d7ea37b8cb39d01f222a Reviewed-on: https://go-review.googlesource.com/c/go/+/503936 Auto-Submit: Bryan Mills TryBot-Result: Gopher Robot Run-TryBot: Bryan Mills Reviewed-by: Ian Lance Taylor (cherry picked from commit 60876717b402f0dd6b4f585827779a9e435400c8) Reviewed-on: https://go-review.googlesource.com/c/go/+/504062 Reviewed-by: Dmitri Shuralyov Reviewed-by: Dmitri Shuralyov Auto-Submit: Dmitri Shuralyov

[release-branch.go1.20] runtime: resolve checkdead panic by refining `startm` lock handling in caller context

2023-06-22T15:28:32Z

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 Reviewed-by: Michael Pratt TryBot-Result: Gopher Robot Run-TryBot: Michael Pratt (cherry picked from commit ff059add10d71fe13239cf893c0cca113de1fc21) Reviewed-on: https://go-review.googlesource.com/c/go/+/504395 Reviewed-by: Lucien Coffe Auto-Submit: Dmitri Shuralyov Run-TryBot: Dmitri Shuralyov

[release-branch.go1.20] runtime: fallback to TEB arbitrary pointer when TLS slots are full

2023-06-22T15:27:07Z

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 Reviewed-by: Cherry Mui Run-TryBot: Quim Muntal Reviewed-by: Bryan Mills Reviewed-by: Alex Brainman TryBot-Result: Gopher Robot (cherry picked from commit 715d53c090ea02dbd73c301684ecbd09b476989e) Reviewed-on: https://go-review.googlesource.com/c/go/+/504475 Reviewed-by: Dmitri Shuralyov Auto-Submit: Dmitri Shuralyov

[release-branch.go1.20] runtime: use 1-byte load for address checking in racecallatomic

2023-06-22T15:14:44Z

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 TryBot-Result: Gopher Robot Reviewed-by: Than McIntosh Reviewed-by: David Chase (cherry picked from commit 1a7709d6af76c06d465c5e969b502fc206f8e687) Reviewed-on: https://go-review.googlesource.com/c/go/+/503976 Auto-Submit: Dmitri Shuralyov Reviewed-by: Austin Clements