go, branch go1.24.6

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

2025-08-06T18:07:24Z

Change-Id: I01fc50fa6e6ea1bd93cbbd17885a8934bf97b223 Reviewed-on: https://go-review.googlesource.com/c/go/+/693715 Reviewed-by: Dmitri Shuralyov Auto-Submit: Gopher Robot TryBot-Bypass: Gopher Robot Reviewed-by: Mark Freeman

[release-branch.go1.24] database/sql: avoid closing Rows while scan is in progress

2025-08-06T17:49:43Z

A database/sql/driver.Rows can return database-owned data from Rows.Next. The driver.Rows documentation doesn't explicitly document the lifetime guarantees for this data, but a reasonable expectation is that the caller of Next should only access it until the next call to Rows.Close or Rows.Next. Avoid violating that constraint when a query is cancelled while a call to database/sql.Rows.Scan (note the difference between the two different Rows types!) is in progress. We previously took care to avoid closing a driver.Rows while the user has access to driver-owned memory via a RawData, but we could still close a driver.Rows while a Scan call was in the process of reading previously-returned driver-owned data. Update the fake DB used in database/sql tests to invalidate returned data to help catch other places we might be incorrectly retaining it. Updates #74831 Fixes #74833 Change-Id: Ice45b5fad51b679c38e3e1d21ef39156b56d6037 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2540 Reviewed-by: Roland Shoemaker Reviewed-by: Neal Patel Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2620 Reviewed-on: https://go-review.googlesource.com/c/go/+/693616 Reviewed-by: Dmitri Shuralyov Auto-Submit: Dmitri Shuralyov TryBot-Bypass: Dmitri Shuralyov Reviewed-by: Mark Freeman

[release-branch.go1.24] os/exec: fix incorrect expansion of "", "." and ".." in LookPath

2025-07-30T20:59:28Z

Fix incorrect expansion of "" and "." when $PATH contains an executable file or, on Windows, a parent directory of a %PATH% element contains an file with the same name as the %PATH% element but with one of the %PATHEXT% extension (ex: C:\utils\bin is in PATH, and C:\utils\bin.exe exists). Fix incorrect expansion of ".." when $PATH contains an element which is an the concatenation of the path to an executable file (or on Windows a path that can be expanded to an executable by appending a %PATHEXT% extension), a path separator and a name. "", "." and ".." are now rejected early with ErrNotFound. Fixes CVE-2025-47906 Fixes #74804 Change-Id: Ie50cc0a660fce8fbdc952a7f2e05c36062dcb50e Reviewed-on: https://go-review.googlesource.com/c/go/+/685755 LUCI-TryBot-Result: Go LUCI Auto-Submit: Damien Neil Reviewed-by: Roland Shoemaker Reviewed-by: Damien Neil (cherry picked from commit e0b07dc22eaab1b003d98ad6d63cdfacc76c5c70) Reviewed-on: https://go-review.googlesource.com/c/go/+/691875 Reviewed-by: Michael Knyszek

[release-branch.go1.24] cmd/compile: for arm64 epilog, do SP increment with a single instruction

2025-07-30T18:54:02Z

That way, the frame is atomically popped. Previously, for big frames the SP was unwound in two steps (because arm64 can only add constants up to 1<<12 in a single instruction). Fixes #74694 Change-Id: I382c249194ad7bc9fc19607c27487c58d90d49e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/689235 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt Reviewed-by: Keith Randall (cherry picked from commit f7cc61e7d7f77521e073137c6045ba73f66ef902) Reviewed-on: https://go-review.googlesource.com/c/go/+/689596

[release-branch.go1.24] os/user: user random name for the test user account

2025-07-30T18:52:37Z

TestImpersonated and TestGroupIdsTestUser are flaky due to sporadic failures when creating the test user account when running the tests from different processes at the same time. This flakiness can be fixed by using a random name for the test user account. For #73523. Fixes #74760. Cq-Include-Trybots: luci.golang.try:go1.24-windows-amd64-longtest Change-Id: Ib2283a888437420502b1c11d876c975f5af4bc03 Reviewed-on: https://go-review.googlesource.com/c/go/+/690175 Auto-Submit: Quim Muntal Reviewed-by: Michael Pratt Reviewed-by: Dmitri Shuralyov TryBot-Bypass: Dmitri Shuralyov (cherry picked from commit 374e3be2eb9b546ef1340f750e343c15a8f87dde) Reviewed-on: https://go-review.googlesource.com/c/go/+/690556 Reviewed-by: Mark Freeman Reviewed-by: Quim Muntal LUCI-TryBot-Result: Go LUCI Auto-Submit: Dmitri Shuralyov

[release-branch.go1.24] runtime: prevent unnecessary zeroing of large objects with pointers

2025-07-10T17:03:34Z

CL 614257 refactored mallocgc but lost an optimization: if a span for a large object is already backed by memory fresh from the OS (and thus zeroed), we don't need to zero it. CL 614257 unconditionally zeroed spans for large objects that contain pointers. This change restores the optimization from before CL 614257, which seems to matter in some real-world programs. While we're here, let's also fix a hole with the garbage collector being able to observe uninitialized memory of the large object is observed by the conservative scanner before being published. The gory details are in a comment in heapSetTypeLarge. In short, this change makes span.largeType an atomic variable, such that the GC can only observe initialized memory if span.largeType != nil. For #72991. Fixes #73800. Change-Id: I2048aeb220ab363d252ffda7d980b8788e9674dc Reviewed-on: https://go-review.googlesource.com/c/go/+/659956 Reviewed-by: Keith Randall LUCI-TryBot-Result: Go LUCI Reviewed-by: Keith Randall Reviewed-by: Felix Geisendörfer (cherry picked from commit df9888ea4e97feb755e452609be5078686370995) Reviewed-on: https://go-review.googlesource.com/c/go/+/682356

[release-branch.go1.24] runtime: stash allpSnapshot on the M

2025-07-10T17:03:11Z

findRunnable takes a snapshot of allp prior to dropping the P because afterwards procresize may mutate allp without synchronization. procresize is careful to never mutate the contents up to cap(allp), so findRunnable can still safely access the Ps in the slice. Unfortunately, growing allp is problematic. If procresize grows the allp backing array, it drops the reference to the old array. allpSnapshot still refers to the old array, but allpSnapshot is on the system stack in findRunnable, which also likely no longer has a P at all. This means that a future GC will not find the reference and can free the array and use it for another allocation. This would corrupt later reads that findRunnable does from the array. The fix is simple: the M struct itself is reachable by the GC, so we can stash the snapshot in the M to ensure it is visible to the GC. The ugliest part of the CL is the cleanup when we are done with the snapshot because there are so many return/goto top sites. I am tempted to put mp.clearAllpSnapshot() in the caller and at top to make this less error prone, at the expensive of extra unnecessary writes. For #74414. For #74416. Change-Id: I6a6a636c484e4f4b34794fd07910b3fffeca830b Reviewed-on: https://go-review.googlesource.com/c/go/+/684460 Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Auto-Submit: Michael Pratt (cherry picked from commit 740857f529ce4074c7f9aa1d6f38db8c4a00246c) Reviewed-on: https://go-review.googlesource.com/c/go/+/685056

[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