go, branch go1.23.11

[release-branch.go1.23] go1.23.11

2025-07-08T17:00:23Z

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

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

2025-07-08T16:29:10Z

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 #74382 Fixes CVE-2025-4674 Change-Id: I2db79f2baacfacfec331ee7c6978c4057d483eba Reviewed-on: https://go-review.googlesource.com/c/go/+/686337 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase Reviewed-by: Carlos Amedee Commit-Queue: Carlos Amedee

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

2025-06-27T17:20:55Z

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 #74402. 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/+/684456 Auto-Submit: Dmitri Shuralyov

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

2025-06-27T17:14:46Z

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 #74289. 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 6bbe5e56d0b4957e0204b464bfd76768b13c9617) Reviewed-on: https://go-review.googlesource.com/c/go/+/684096 Reviewed-by: Dmitri Shuralyov Auto-Submit: Dmitri Shuralyov

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

2025-06-27T17:11:17Z

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 #74293. 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/+/684095 Auto-Submit: Dmitri Shuralyov Reviewed-by: Dmitri Shuralyov

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

2025-06-27T17:06:42Z

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 #74362. 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/+/684097 Auto-Submit: Dmitri Shuralyov Reviewed-by: Michael Pratt Reviewed-by: Dmitri Shuralyov

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

2025-06-12T03:49:18Z

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 #73907 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/+/676918

[release-branch.go1.23] go1.23.10

2025-06-05T18:34:47Z

Change-Id: Id4ed8879352dfe662a0ab96981a8d59e2fd80767 Reviewed-on: https://go-review.googlesource.com/c/go/+/679219 Reviewed-by: Carlos Amedee Reviewed-by: Michael Knyszek TryBot-Bypass: Carlos Amedee

[release-branch.go1.23] net/http: strip sensitive proxy headers from redirect requests

2025-06-05T18:10:16Z

Similarly to Authentication entries, Proxy-Authentication entries should be stripped to ensure sensitive information is not leaked on redirects outside of the original domain. https://fetch.spec.whatwg.org/#authentication-entries Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue. Updates golang/go#73816 Fixes golang/go#73905 Fixes CVE-2025-4673 Change-Id: I1615f31977a2fd014fbc12aae43f82692315a6d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/679255 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

[release-branch.go1.23] os: don't follow symlinks on Windows when O_CREATE|O_EXCL

2025-05-29T17:56:13Z

(This cherry-pick includes both CL 672396 and CL 676655.) Match standard Unix behavior: Symlinks are not followed when O_CREATE|O_EXCL is passed to open. Thanks to Junyoung Park and Dong-uk Kim of KAIST Hacking Lab for discovering this issue. For #73702 Fixes #73719 Fixes CVE-2025-0913 Change-Id: Ieb46a6780c5e9a6090b09cd34290f04a8e3b0ca5 Reviewed-on: https://go-review.googlesource.com/c/go/+/672396 Auto-Submit: Damien Neil LUCI-TryBot-Result: Go LUCI Reviewed-by: Alan Donovan Reviewed-on: https://go-review.googlesource.com/c/go/+/677195 TryBot-Bypass: Michael Knyszek Reviewed-by: Michael Knyszek