go, branch go1.24.5

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

2025-07-08T17:00:27Z

Change-Id: I0d1554956b9fb4453fc6cce977d67c56476e3624 Reviewed-on: https://go-review.googlesource.com/c/go/+/686455 Reviewed-by: Carlos Amedee Auto-Submit: Gopher Robot Reviewed-by: David Chase TryBot-Bypass: Gopher Robot

[release-branch.go1.24] cmd/go: disable support for multiple vcs in one module

2025-07-08T16:29:29Z

Removes the somewhat redundant vcs.FromDir, "allowNesting" argument, which was always enabled, and disallow multiple VCS metadata folders being present in a single directory. This makes VCS injection attacks much more difficult. Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior. Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue. Updates #74380 Fixes #74381 Fixes CVE-2025-4674 Change-Id: I6c7925b034d60b80d7698cca677b00bdcc67f24e Reviewed-on: https://go-review.googlesource.com/c/go/+/686395 Reviewed-by: David Chase LUCI-TryBot-Result: Go LUCI Reviewed-by: Carlos Amedee Commit-Queue: Carlos Amedee

[release-branch.go1.24] cmd/link: permit a larger size BSS reference to a smaller DATA symbol

2025-06-27T17:20:50Z

Currently, if there is a BSS reference and a DATA symbol definition with the same name, we pick the DATA symbol, as it contains the right content. In this case, if the BSS reference has a larger size, we error out, because it is not safe to access a smaller symbol as if it has a larger size. Sometimes code declares a global variable in Go and defines it in assembly with content. They are expected to be of the same size. However, in ASAN mode, we insert a red zone for the variable on the Go side, making it have a larger size, whereas the assembly symbol is unchanged. This causes the Go reference (BSS) has a larger size than the assembly definition (DATA). It results in an error currently. This code is valid and safe, so we should permit that. We support this case by increasing the symbol size to match the larger size (of the BSS side). The symbol content (from the DATA side) is kept. In some sense, we merge the two symbols. When loading symbols, it is not easy to change its size (as the object file may be mapped read-only), so we add it to a fixup list, and fix it up later after all Go symbols are loaded. This is a very rare case, so the list should not be long. We could limit this to just ASAN mode. But it seems okay to allow this in general. As long as the symbol has the larger size, it is safe to access it with the larger size. Updates #74314. Fixes #74403. Change-Id: I3ee6e46161d8f59500e2b81befea11e563355a57 Reviewed-on: https://go-review.googlesource.com/c/go/+/684236 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase (cherry picked from commit 0f8ab2db177baee7b04182f5641693df3b212aa9) Reviewed-on: https://go-review.googlesource.com/c/go/+/684455 Auto-Submit: Dmitri Shuralyov

[release-branch.go1.24] runtime: set mspan limit field early and eagerly

2025-06-27T17:13:03Z

Currently the mspan limit field is set after allocSpan returns, *after* the span has already been published to the GC (including the conservative scanner). But the limit field is load-bearing, because it's checked to filter out invalid pointers. A stale limit value could cause a crash by having the conservative scanner access allocBits out of bounds. Fix this by setting the mspan limit field before publishing the span. For large objects and arena chunks, we adjust the limit down after allocSpan because we don't have access to the true object's size from allocSpan. However this is safe, since we first initialize the limit to something definitely safe (the actual span bounds) and only adjust it down after. Adjusting it down has the benefit of more precise debug output, but the window in which it's imprecise is also fine because a single object (logically, with arena chunks) occupies the whole span, so the 'invalid' part of the memory will just safely point back to that object. We can't do this for smaller objects because the limit will include space that does *not* contain any valid objects. For #74288. Fixes #74290. Change-Id: I0a22e5b9bccc1bfdf51d2b73ea7130f1b99c0c7c Reviewed-on: https://go-review.googlesource.com/c/go/+/682655 Reviewed-by: Keith Randall Auto-Submit: Michael Knyszek LUCI-TryBot-Result: Go LUCI Reviewed-by: Keith Randall (cherry picked from commit 4c7567290ced9c4dc629f2386f2eebfebba95ce6) Reviewed-on: https://go-review.googlesource.com/c/go/+/684079 Auto-Submit: Dmitri Shuralyov Reviewed-by: Dmitri Shuralyov

[release-branch.go1.24] runtime: prevent mutual deadlock between GC stopTheWorld and suspendG

2025-06-27T17:09:36Z

Almost everywhere we stop the world we casGToWaitingForGC to prevent mutual deadlock with the GC trying to scan our stack. This historically was only necessary if we weren't stopping the world to change the GC phase, because what we were worried about was mutual deadlock with mark workers' use of suspendG. And, they were the only users of suspendG. In Go 1.22 this changed. The execution tracer began using suspendG, too. This leads to the possibility of mutual deadlock between the execution tracer and a goroutine trying to start or end the GC mark phase. The fix is simple: make the stop-the-world calls for the GC also call casGToWaitingForGC. This way, suspendG is guaranteed to make progress in this circumstance, and once it completes, the stop-the-world can complete as well. We can take this a step further, though, and move casGToWaitingForGC into stopTheWorldWithSema, since there's no longer really a place we can afford to skip this detail. While we're here, rename casGToWaitingForGC to casGToWaitingForSuspendG, since the GC is now not the only potential source of mutual deadlock. For #72740. Fixes #74294. Change-Id: I5e3739a463ef3e8173ad33c531e696e46260692f Reviewed-on: https://go-review.googlesource.com/c/go/+/681501 Reviewed-by: Carlos Amedee Auto-Submit: Michael Knyszek LUCI-TryBot-Result: Go LUCI Reviewed-by: Cherry Mui (cherry picked from commit c6ac7362888c25dd1251adaa11e1503cf78ec26d) Reviewed-on: https://go-review.googlesource.com/c/go/+/684078 Auto-Submit: Dmitri Shuralyov Reviewed-by: Dmitri Shuralyov

[release-branch.go1.24] runtime: handle system goroutines later in goroutine profiling

2025-06-27T17:04:49Z

In Go 1.24 and earlier, it's possible for a just-starting finalizer goroutine to have its stack traced in goroutine profiles even though it shouldn't, because it wasn't visible to the goroutine profile STW. This can also bump out other stacks, because the goroutine profiler wasn't expecting to have another stack. Fix this by letting all system goroutines participate in the goroutine profiler's state machine, like in the CL this is cherry-picking. This ensures that the finalizer goroutine will be counted as a system goroutine in this just-starting state, but still composes with the old way of doing things, because the finalizer goroutine is advanced to the terminal state during the STW. In Go 1.25, this is fixing a slightly different issue, but the root of the problem is the same: all goroutines should participate in the profiler's state machine, and they do not. For #74090. Fixes #74363. Change-Id: Icb9a164a033be22aaa942d19e828e895f700ca74 Reviewed-on: https://go-review.googlesource.com/c/go/+/680477 Reviewed-by: Carlos Amedee Auto-Submit: Michael Knyszek LUCI-TryBot-Result: Go LUCI (cherry picked from commit 281cfcfc1b15fbb87fd32660b0a1d50be996d108) Reviewed-on: https://go-review.googlesource.com/c/go/+/684017 Reviewed-by: Dmitri Shuralyov Reviewed-by: Michael Pratt Auto-Submit: Dmitri Shuralyov

[release-branch.go1.24] cmd/go/internal/fips140: ignore GOEXPERIMENT on error

2025-06-26T17:26:56Z

During toolchain selection, the GOEXPERIMENT value may not be valid for the current version (but it is valid for the selected version). In this case, cfg.ExperimentErr is set and cfg.Experiment is nil. Normally cmd/go main exits when ExperimentErr is set, so Experiment is ~never nil. But that is skipped during toolchain selection, and fips140.Init is used during toolchain selection. For #74111. Fixes #74113 Change-Id: I6a6a636c65ee5831feaf3d29993a60613bbec6f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/680976 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Matloob Reviewed-by: Junyang Shao Auto-Submit: Michael Pratt (cherry picked from commit 8552bcf7c261cd150d0074c4ec7e2412b20af0a5) Reviewed-on: https://go-review.googlesource.com/c/go/+/682735 Auto-Submit: Dmitri Shuralyov Reviewed-by: Michael Matloob

[release-branch.go1.24] runtime: add missing unlock in sysReserveAlignedSbrk

2025-06-25T19:28:15Z

sysReserveAlignedSbrk locks memlock at entry, but it is not unlocked at one of the return path. Add the missing unlock. Updates #74339. Fixes #74346. Change-Id: Ib641bc348aca41494ec410e2c4eb9857f3362484 Reviewed-on: https://go-review.googlesource.com/c/go/+/683295 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase Reviewed-by: Michael Knyszek (cherry picked from commit 456a90aa1618a6c3aa49ecba46969128e2bfa26f) Reviewed-on: https://go-review.googlesource.com/c/go/+/684016 Auto-Submit: Dmitri Shuralyov

[release-branch.go1.24] cmd/compile/internal/ssa: fix PPC64 merging of (AND (S[RL]Dconst ...)

2025-06-12T03:49:41Z

CL 622236 forgot to check the mask was also a 32 bit rotate mask. Add a modified version of isPPC64WordRotateMask which valids the mask is contiguous and fits inside a uint32. I don't this is possible when merging SRDconst, the first check should always reject such combines. But, be extra careful and do it there too. Fixes #74098 Change-Id: Ie95f74ec5e7d89dc761511126db814f886a7a435 Reviewed-on: https://go-review.googlesource.com/c/go/+/679775 Auto-Submit: Keith Randall Reviewed-by: Jayanth Krishnamurthy Reviewed-by: Keith Randall Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Keith Randall Reviewed-on: https://go-review.googlesource.com/c/go/+/680835

[release-branch.go1.24] cmd/compile: do nil check before calling duff functions, on arm64 and amd64

2025-06-12T03:48:50Z

On these platforms, we set up a frame pointer record below the current stack pointer, so when we're in duffcopy or duffzero, we get a reasonable traceback. See #73753. But because this frame pointer record is below SP, it is vulnerable. Anything that adds a new stack frame to the stack might clobber it. Which actually happens in #73748 on amd64. I have not yet come across a repro on arm64, but might as well be safe here. The only real situation this could happen is when duffzero or duffcopy is passed a nil pointer. So we can just avoid the problem by doing the nil check outside duffzero/duffcopy. That way we never add a frame below duffzero/duffcopy. (Most other ways to get a new frame below the current one, like async preempt or debugger-generated calls, don't apply to duffzero/duffcopy because they are runtime functions; we're not allowed to preempt there.) Longer term, we should stop putting stuff below SP. #73753 will include that as part of its remit. But that's not for 1.25, so we'll do the simple thing for 1.25 for this issue. Fixes #73908 Change-Id: I913c49ee46dcaee8fb439415a4531f7b59d0f612 Reviewed-on: https://go-review.googlesource.com/c/go/+/676916 LUCI-TryBot-Result: Go LUCI Reviewed-by: Cherry Mui Reviewed-by: Keith Randall (cherry picked from commit dbaa2d3e6525a29defdff16f354881a93974dd2e) Reviewed-on: https://go-review.googlesource.com/c/go/+/677095