go, branch go1.17.13

[release-branch.go1.17] go1.17.13

2022-08-01T15:12:52Z

Change-Id: Id21203787dc0bbca2548044d7bcc442204dfdd7d Reviewed-on: https://go-review.googlesource.com/c/go/+/420554 Auto-Submit: Gopher Robot Reviewed-by: Heschi Kreinick Run-TryBot: Gopher Robot Reviewed-by: Cherry Mui Reviewed-by: Dmitri Shuralyov TryBot-Result: Gopher Robot

[release-branch.go1.17] math/big: check buffer lengths in GobDecode

2022-07-29T14:06:18Z

In Float.GobDecode and Rat.GobDecode, check buffer sizes before indexing slices. Updates #53871 Fixes #54094 Change-Id: I1b652c32c2bc7a0e8aa7620f7be9b2740c568b0a Reviewed-on: https://go-review.googlesource.com/c/go/+/417774 TryBot-Result: Gopher Robot Reviewed-by: Tatiana Bradley Run-TryBot: Roland Shoemaker (cherry picked from commit 055113ef364337607e3e72ed7d48df67fde6fc66) Reviewed-on: https://go-review.googlesource.com/c/go/+/419814 Reviewed-by: Julie Qiu

[release-branch.go1.17] cmd/compile: do not use special literal assignment if LHS is address-taken

2022-07-26T14:16:52Z

A composite literal assignment x = T{field: v} may be compiled to x = T{} x.field = v We already do not use this form is RHS uses LHS. If LHS is address-taken, RHS may uses LHS implicitly, e.g. v = &x.field x = T{field: *v} The lowering above would change the value of RHS (*v). Updates #52953. Fixes #52960. Change-Id: I3f798e00598aaa550b8c17182c7472fef440d483 Reviewed-on: https://go-review.googlesource.com/c/go/+/407014 Reviewed-by: Cuong Manh Le Run-TryBot: Cherry Mui TryBot-Result: Gopher Robot Reviewed-by: Michael Knyszek (cherry picked from commit 1c77137d4fdfbb3e7e8d9efaab3bab5ee736a19d) Reviewed-on: https://go-review.googlesource.com/c/go/+/419451 Reviewed-by: Matthew Dempsky

[release-branch.go1.17] cmd/compile: fix prove pass when upper condition is <= maxint

2022-07-25T23:15:10Z

When the terminating condition is <= X, we need to make sure that X+step doesn't overflow. Fixes #53617 Change-Id: I36e5384d05b4d7168e48db6094200fcae409bfe5 Reviewed-on: https://go-review.googlesource.com/c/go/+/415219 Reviewed-by: Than McIntosh Run-TryBot: David Chase Reviewed-by: David Chase TryBot-Result: Gopher Robot Run-TryBot: Keith Randall (cherry picked from commit 31b8c23c5702f129aca9241bbb2132c90b1929cc) Reviewed-on: https://go-review.googlesource.com/c/go/+/415415 Reviewed-by: Keith Randall

[release-branch.go1.17] runtime: clear timerModifiedEarliest when last timer is deleted

2022-07-25T23:11:36Z

timerModifiedEarliest contains the lowest possible expiration for a modified earlier timer, which may be earlier than timer0When because we haven't yet updated the heap. Note "may", as the modified earlier timer that set timerModifiedEarliest may have since been modified later or deleted. We can clear timerModifiedEarliest when the last timer is deleted because by definition there must not be any modified earlier timers. Why does this matter? checkTimersNoP claims that there is work to do if timerModifiedEarliest has passed, causing findRunnable to loop back around to checkTimers. But the code to clean up timerModifiedEarliest in checkTimers (i.e., the call to adjusttimers) is conditional behind a check that len(pp.timers) > 0. Without clearing timerModifiedEarliest, a spinning M that would otherwise go to sleep will busy loop in findRunnable until some other work is available. Note that changing the condition on the call to adjusttimers would also be a valid fix. I took this approach because it feels a bit cleaner to clean up timerModifiedEarliest as soon as it is known to be irrelevant. For #51654. Fixes #53846. Change-Id: I3f3787c67781cac7ce87939c5706cef8db927dd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/417434 Auto-Submit: Michael Pratt TryBot-Result: Gopher Robot Run-TryBot: Michael Pratt Reviewed-by: Michael Knyszek Reviewed-by: Ian Lance Taylor (cherry picked from commit c006b7ac2765252f397dec40fef610a3c17d956d) Reviewed-on: https://go-review.googlesource.com/c/go/+/417476

[release-branch.go1.17] runtime: use saved LR when unwinding through morestack

2022-07-22T17:25:33Z

On LR machine, consider F calling G calling H, which grows stack. The stack looks like ... G's frame: ... locals ... saved LR = return PC in F <- SP points here at morestack H's frame (to be created) At morestack, we save gp.sched.pc = H's morestack call gp.sched.sp = H's entry SP (the arrow above) gp.sched.lr = return PC in G Currently, when unwinding through morestack (if _TraceJumpStack is set), we switch PC and SP but not LR. We then have frame.pc = H's morestack call frame.sp = H's entry SP (the arrow above) As LR is not set, we load it from stack at *sp, so frame.lr = return PC in F As the SP hasn't decremented at the morestack call, frame.fp = frame.sp = H's entry SP Unwinding a frame, we have frame.pc = old frame.lr = return PC in F frame.sp = old frame.fp = H's entry SP a.k.a. G's SP The PC and SP don't match. The unwinding will go off if F and G have different frame sizes. Fix this by preserving the LR when switching stack. Also add code to detect infinite loop in unwinding. TODO: add some test. I can reproduce the infinite loop (or throw with added check) but the frequency is low. Fixes #53111. Updates #52116. Change-Id: I6e1294f1c6e55f664c962767a1cf6c466a0c0eff Reviewed-on: https://go-review.googlesource.com/c/go/+/400575 TryBot-Result: Gopher Robot Run-TryBot: Cherry Mui Reviewed-by: Eric Fang Reviewed-by: Benny Siegert (cherry picked from commit 74f00094220f26c80fbaab6eca28c3a664897d24) Reviewed-on: https://go-review.googlesource.com/c/go/+/408822 Reviewed-by: Austin Clements

[release-branch.go1.17] go1.17.12

2022-07-12T20:15:34Z

Change-Id: I12bfc6a625d61a7a25ecdaa10c8f78953c4c3bcf Reviewed-on: https://go-review.googlesource.com/c/go/+/417178 Run-TryBot: Gopher Robot Auto-Submit: Gopher Robot TryBot-Result: Gopher Robot Reviewed-by: Michael Knyszek Reviewed-by: Heschi Kreinick

[release-branch.go1.17] encoding/gob: add a depth limit for ignored fields

2022-07-12T15:20:44Z

Enforce a nesting limit of 10,000 for ignored fields during decoding of messages. This prevents the possibility of triggering stack exhaustion. Fixes #53709 Updates #53615 Fixes CVE-2022-30635 Change-Id: I05103d06dd5ca3945fcba3c1f5d3b5a645e8fb0f Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1484771 Reviewed-by: Damien Neil Reviewed-by: Tatiana Bradley (cherry picked from commit 55e8f938d22bfec29cc9dc9671044c5a41d1ea9c) Reviewed-on: https://go-review.googlesource.com/c/go/+/417074 Run-TryBot: Heschi Kreinick TryBot-Result: Gopher Robot Reviewed-by: Heschi Kreinick

[release-branch.go1.17] path/filepath: fix stack exhaustion in Glob

2022-07-12T15:20:41Z

A limit is added to the number of path separators allowed by an input to Glob, to prevent stack exhaustion issues. Thanks to Juho Nurminen of Mattermost who reported the issue. Fixes #53713 Updates #53416 Fixes CVE-2022-30632 Change-Id: I1b9fd4faa85411a05dbc91dceae1c0c8eb021f07 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1498176 Reviewed-by: Roland Shoemaker (cherry picked from commit d182a6d1217fd0d04c9babfa9a7ccd3515435c39) Reviewed-on: https://go-review.googlesource.com/c/go/+/417073 Reviewed-by: Heschi Kreinick TryBot-Result: Gopher Robot Run-TryBot: Michael Knyszek

[release-branch.go1.17] io/fs: fix stack exhaustion in Glob

2022-07-12T15:20:37Z

A limit is added to the number of path separators allowed by an input to Glob, to prevent stack exhaustion issues. Thanks to Juho Nurminen of Mattermost who reported a similar issue in path/filepath. Fixes #53719 Updates #53415 Fixes CVE-2022-30630 Change-Id: I5a9d02591fed90cd3d52627f5945f1301e53465d Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1497588 Reviewed-by: Roland Shoemaker (cherry picked from commit fdccc5d7bd0f276d0a8de3a818ca844f0bed5d97) Reviewed-on: https://go-review.googlesource.com/c/go/+/417072 Reviewed-by: Heschi Kreinick TryBot-Result: Gopher Robot Run-TryBot: Michael Knyszek