summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [release-branch.go1.20] crypto/rsa: use BoringCrypto for 4096 bit keysrelease-branch.go1.20Filippo Valsorda2023-05-171-1/+2
| | | | | | | | | | | | | | | Updates #58803 Fixes #58927 Change-Id: I097938ff61dae2b65214f8d0126d68de63525f5b Reviewed-on: https://go-review.googlesource.com/c/go/+/474515 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit 7bc3281747030877e13d218ba12c6e95fcf4e7d4) Reviewed-on: https://go-review.googlesource.com/c/go/+/495735 Reviewed-by: Heschi Kreinick <heschi@google.com>
* [release-branch.go1.20] cmd/compile: fix bswap/load rewrite rulesKeith Randall2023-05-112-48/+80
| | | | | | | | | | | | | | | | | | When combining a byteswap and a load, the resulting combined op must go in the load's block, not the byteswap's block, as the load has a memory argument that might only be valid in its original block. Fixes #59975 Change-Id: Icd84863ef3a9ca1fc22f2bb794a003f2808c746f Reviewed-on: https://go-review.googlesource.com/c/go/+/492616 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit 10141676d15665ed8a0255cfc5585ad50444f4ee) Reviewed-on: https://go-review.googlesource.com/c/go/+/492696
* [release-branch.go1.20] go1.20.4go1.20.4Gopher Robot2023-05-021-1/+1
| | | | | | | | | | Change-Id: I12cd69dd6b1c7c9620738a0d89b10e0a330a3004 Reviewed-on: https://go-review.googlesource.com/c/go/+/491435 Run-TryBot: Gopher Robot <gobot@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
* [release-branch.go1.20] html/template: emit filterFailsafe for empty ↵Roland Shoemaker2023-05-023-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unquoted attr value An unquoted action used as an attribute value can result in unsafe behavior if it is empty, as HTML normalization will result in unexpected attributes, and may allow attribute injection. If executing a template results in a empty unquoted attribute value, emit filterFailsafe instead. Thanks to Juho Nurminen of Mattermost for reporting this issue. For #59722 Fixes #59816 Fixes CVE-2023-29400 Change-Id: Ia38d1b536ae2b4af5323a6c6d861e3c057c2570a Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1826631 Reviewed-by: Julie Qiu <julieqiu@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1851494 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491358 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.20] html/template: handle all JS whitespace charactersRoland Shoemaker2023-05-022-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Rather than just a small set. Character class as defined by \s [0]. Thanks to Juho Nurminen of Mattermost for reporting this. For #59721 Fixes #59814 Fixes CVE-2023-24540 [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Character_Classes Change-Id: I56d4fa1ef08125b417106ee7dbfb5b0923b901ba Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1821459 Reviewed-by: Julie Qiu <julieqiu@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1851493 TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491356 Run-TryBot: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.20] html/template: disallow angle brackets in CSS valuesRoland Shoemaker2023-05-022-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Angle brackets should not appear in CSS contexts, as they may affect token boundaries (such as closing a <style> tag, resulting in injection). Instead emit filterFailsafe, matching the behavior for other dangerous characters. Thanks to Juho Nurminen of Mattermost for reporting this issue. For #59720 Fixes #59812 Fixes CVE-2023-24539 Change-Id: Iccc659c9a18415992b0c05c178792228e3a7bae4 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1826636 Reviewed-by: Julie Qiu <julieqiu@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1851492 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491336 Run-TryBot: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] Revert "net/http: FileServer method check + minimal ↵Damien Neil2023-04-252-56/+5
| | | | | | | | | | | | | | | | | | | | | | | OPTIONS implementation" This reverts https://go.dev/cl/413554 Reason for revert: Backwards-incompatible change in behavior. For #53501 For #59375 Fixes #59469 Change-Id: Ic3f63b378f9c819599b32e5e6e410f6163849317 Reviewed-on: https://go-review.googlesource.com/c/go/+/482635 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit c02fa75086dbc6db0d90f477e7b4c839140fdeb2) Reviewed-on: https://go-review.googlesource.com/c/go/+/488635 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
* cmd/compile/internal/importer,go/internal/gcimporter: use the 'go' command ↵Bryan C. Mills2023-04-242-2/+4
| | | | | | | | | | | | | | | | | | | | from build.Default.GOROOT in lookupGorootExport Also set GOROOT explicitly in case it is set to something else in the caller's environment. Updates #59598. Fixes #59637. Change-Id: I5599ed1183b23187fc3b976786f3c320d42ef4f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/484756 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> (cherry picked from commit 750e91152bbd1cb2869660ddb80f2b3adcfd1f9b) Reviewed-on: https://go-review.googlesource.com/c/go/+/484758 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/tls: fix PSK binder calculationTero Saarni2023-04-242-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | When server and client have mismatch in curve preference, the server will send HelloRetryRequest during TLSv1.3 PSK resumption. There was a bug introduced by Go1.19.6 or later and Go1.20.1 or later, that makes the client calculate the PSK binder hash incorrectly. Server will reject the TLS handshake by sending alert: invalid PSK binder. For #59424. Fixes #59540. Change-Id: I2ca8948474275740a36d991c057b62a13392dbb9 GitHub-Last-Rev: 1aad9bcf27f563449c1a7ed6d0dd1d247cc65713 GitHub-Pull-Request: golang/go#59425 Reviewed-on: https://go-review.googlesource.com/c/go/+/481955 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> (cherry picked from commit 2c70690451f1484607a9172a4c24f78ae832dcb0) Reviewed-on: https://go-review.googlesource.com/c/go/+/488055 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
* [release-branch.go1.20] cmd/compile: fix reproducible build of aliased ↵Matthew Dempsky2023-04-242-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | generic types Due to a missing "&& !alias" check, the unified linker was treating type aliases the same as defined types for the purpose of exporting method bodies. The methods will get exported anyway alongside the aliased type, so this mistake is normally harmless. However, if multiple type aliases instantiated the same generic type but with different type arguments, this could result in the same (generic) method body being exported multiple times under different symbol names. Further, because bodies aren't expected to be exported multiple times, we were sorting them simply based on index. And consequently, the sort wasn't total and is sensitive to the map iteration order used while ranging over linker.bodies. The fix is simply to add the missing "&& !alias" check, so that we don't end up with duplicate bodies in the first place. Thanks rsc@ for providing a minimal repro case. Fixes #59585. Change-Id: Iaa55968cc7110b601e2f0f9b620901c2d55f7014 Reviewed-on: https://go-review.googlesource.com/c/go/+/484155 Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> (cherry picked from commit f58c6cccc44752146aabcd50a30865e34817a4b4) Reviewed-on: https://go-review.googlesource.com/c/go/+/484160 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] cmd/compile: remove broken LEA "optimization"David Chase2023-04-242-401/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | CL 440035 added rewrite rules to simplify "costly" LEA instructions, but the types in the rewrites were wrong and the code would go bad if the wrong-typed register was spilled. CL 482536 attempted to fix this by correcting the type in the rewrite, but that "fix" broke something on windows-amd64-race. Instead / for-now, remove the offending rewrite rules. Updates #21735. Updates #59432. Fixes #59468. Change-Id: I0497c42db414f2055e1378e0a53e2bceee9cd5d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/482820 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 6a97a60b4b80dfa9db91200c054d734e18dda115) Reviewed-on: https://go-review.googlesource.com/c/go/+/482164 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
* [release-branch.go1.20] cmd/compile: use correct type for byteswaps on ↵Keith Randall2023-04-245-72/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multi-byte stores Use the type of the store for the byteswap, not the type of the store's value argument. Normally when we're storing a 16-bit value, the value being stored is also typed as 16 bits. But sometimes it is typed as something smaller, usually because it is the result of an upcast from a smaller value, and that upcast needs no instructions. If the type of the store's arg is thinner than the type being stored, and the byteswap'd value uses that thinner type, and the byteswap'd value needs to be spilled & restored, that spill/restore happens using the thinner type, which causes us to lose some of the top bits of the value. Fixes #59374 Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit b3bc8620f89153fddc1a30ee17c1d93654ed4314) Reviewed-on: https://go-review.googlesource.com/c/go/+/483176 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] syscall: restore original NOFILE rlimit in child processIan Lance Taylor2023-04-1466-90/+380
| | | | | | | | | | | | | | | | | | | | | | If we increased the NOFILE rlimit when starting the program, restore the original rlimit when forking a child process. In CL 393354 the os package was changed to raise the open file rlimit at program start. That code is not inherently tied to the os package. This CL moves it into the syscall package. This is a backport of CLs 476096 and 476097 from trunk. For #46279 Fixes #59064 Change-Id: Ib813de896de0a5d28fa2b29afdf414a89fbe7b2a Reviewed-on: https://go-review.googlesource.com/c/go/+/478659 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
* [release-branch.go1.20] cmd/compile: fix ir.StaticValue for ORANGEJunwei Zuo2023-04-123-0/+38
| | | | | | | | | | | | | | | | | | Range statement will mutate the key and value, so we should treat them as reassigned. Fixes #59580 Change-Id: I9c6b67d938760a0c6a1d9739f2737c67af4a3a10 Reviewed-on: https://go-review.googlesource.com/c/go/+/483855 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit 89567a35c11c343cf765d6fb1270e1250e50d83f) Reviewed-on: https://go-review.googlesource.com/c/go/+/484136 Run-TryBot: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.20] cmd/compile: don't set range expr key/value type if ↵Cuong Manh Le2023-04-052-1/+27
| | | | | | | | | | | | | | | | | | already set Unified IR already records the correct type for them. Fixes #59450 Change-Id: I275c45b48f67bde55c8e2079d60b5868d0acde7f Reviewed-on: https://go-review.googlesource.com/c/go/+/481555 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/482655 Auto-Submit: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] crypto/subtle: don't cast to *uintptr when word size ↵Keith Randall2023-04-052-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | is 0 Casting to a *uintptr is not ok if there isn't at least 8 bytes of data backing that pointer (on 64-bit archs). So although we end up making a slice of 0 length with that pointer, the cast itself doesn't know that. Instead, bail early if the result is going to be 0 length. Fixes #59336 Change-Id: Id3c0e09d341d838835c0382cccfb0f71dc3dc7e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/480575 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> (cherry picked from commit 297cf6dd31bd99fc4ccda320aa3d4faf290ab278) Reviewed-on: https://go-review.googlesource.com/c/go/+/481238 Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] html/template,mime/multipart: document new GODEBUG ↵Michael Anthony Knyszek2023-04-052-0/+22
| | | | | | | | | | | | | | | | | | | | settings This change documents the new GODEBUG settings introduced for html/template and mime/multipart, released with Go 1.19.8 and Go 1.20.3 as part of a security fix. Updates #59153. For #59270. Updates #59234. For #59272. Change-Id: I25f4d8245da3301dccccfb44da8ff1a5985392a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/482555 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] go1.20.3go1.20.3Gopher Robot2023-04-041-1/+1
| | | | | | | | | | Change-Id: I1ca3074262203c6f250c902ca087d244edf9eb96 Reviewed-on: https://go-review.googlesource.com/c/go/+/482097 TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Gopher Robot <gobot@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.20] html/template: disallow actions in JS template literalsRoland Shoemaker2023-04-049-33/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ECMAScript 6 introduced template literals[0][1] which are delimited with backticks. These need to be escaped in a similar fashion to the delimiters for other string literals. Additionally template literals can contain special syntax for string interpolation. There is no clear way to allow safe insertion of actions within JS template literals, as handling (JS) string interpolation inside of these literals is rather complex. As such we've chosen to simply disallow template actions within these template literals. A new error code is added for this parsing failure case, errJsTmplLit, but it is unexported as it is not backwards compatible with other minor release versions to introduce an API change in a minor release. We will export this code in the next major release. The previous behavior (with the cavet that backticks are now escaped properly) can be re-enabled with GODEBUG=jstmpllitinterp=1. This change subsumes CL471455. Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this issue. Fixes CVE-2023-24538 For #59234 Fixes #59272 [0] https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-template-literals [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals Change-Id: Idff74ec386e9b73d6e9a3c9f71990eabc0ce7506 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802457 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802688 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481993 Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.20] go/scanner: reject large line and column numbers in ↵Damien Neil2023-04-042-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | //line directives Setting a large line or column number using a //line directive can cause integer overflow even in small source files. Limit line and column numbers in //line directives to 2^30-1, which is small enough to avoid int32 overflow on all reasonbly-sized files. Fixes CVE-2023-24537 For #59180 Fixes #59274 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802456 Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Run-TryBot: Damien Neil <dneil@google.com> Change-Id: Ib9c5cb38428ed34ab129d451b00a2998e72c861c Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802401 TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481992 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] mime/multipart: limit parsed mime message sizesDamien Neil2023-04-045-19/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The parsed forms of MIME headers and multipart forms can consume substantially more memory than the size of the input data. A malicious input containing a very large number of headers or form parts can cause excessively large memory allocations. Set limits on the size of MIME data: Reader.NextPart and Reader.NextRawPart limit the the number of headers in a part to 10000. Reader.ReadForm limits the total number of headers in all FileHeaders to 10000. Both of these limits may be set with with GODEBUG=multipartmaxheaders=<values>. Reader.ReadForm limits the number of parts in a form to 1000. This limit may be set with GODEBUG=multipartmaxparts=<value>. Thanks for Jakob Ackermann (@das7pad) for reporting this issue. For CVE-2023-24536 For #59153 For #59270 Change-Id: I36ddceead7f8292c327286fd8694e6113d3b4977 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802455 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802608 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481991 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] net/textproto, mime/multipart: improve accounting of ↵Damien Neil2023-04-043-35/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-file data For requests containing large numbers of small parts, memory consumption of a parsed form could be about 250% over the estimated size. When considering the size of parsed forms, account for the size of FileHeader structs and increase the estimate of memory consumed by map entries. Thanks to Jakob Ackermann (@das7pad) for reporting this issue. For CVE-2023-24536 For #59153 For #59270 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802454 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Change-Id: I9753aa1f8a1b1479c160f870def3b7081b6847ac Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802399 TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481990 TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.20] mime/multipart: avoid excessive copy buffer ↵Damien Neil2023-04-042-3/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | allocations in ReadForm When copying form data to disk with io.Copy, allocate only one copy buffer and reuse it rather than creating two buffers per file (one from io.multiReader.WriteTo, and a second one from os.File.ReadFrom). Thanks to Jakob Ackermann (@das7pad) for reporting this issue. For CVE-2023-24536 For #59153 For #59270 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802453 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Change-Id: I44ef17c4b4964cdac2858317275594194801fee3 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802398 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481989 Auto-Submit: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.20] net/textproto: avoid overpredicting the number of ↵Damien Neil2023-04-042-4/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MIME header keys A parsed MIME header is a map[string][]string. In the common case, a header contains many one-element []string slices. To avoid allocating a separate slice for each key, ReadMIMEHeader looks ahead in the input to predict the number of keys that will be parsed, and allocates a single []string of that length. The individual slices are then allocated out of the larger one. The prediction of the number of header keys was done by counting newlines in the input buffer, which does not take into account header continuation lines (where a header key/value spans multiple lines) or the end of the header block and the start of the body. This could lead to a substantial amount of overallocation, for example when the body consists of nothing but a large block of newlines. Fix header key count prediction to take into account the end of the headers (indicated by a blank line) and continuation lines (starting with whitespace). Thanks to Jakob Ackermann (@das7pad) for reporting this issue. Fixes CVE-2023-24534 For #58975 Fixes #59268 Change-Id: I0591593e67b6fdba22a32dcc3334fad797727f5c Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802452 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802397 Run-TryBot: Roland Shoemaker <bracewell@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/481988 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.20] cmd/internal/obj/ppc64: fix incorrect base reg ↵Lynn Boger2023-03-291-4/+9
| | | | | | | | | | | | | | | | | | causing segv This fixes a segv that was reported due to building minio. The problem occurred because of an incorrect selection of the base register, which was introduced by CL 306369. Fixes #59220 Change-Id: Ieb77b2afa8fb4e6f3943df5ce138679f6750d376 Reviewed-on: https://go-review.googlesource.com/c/go/+/479475 Reviewed-by: Archana Ravindar <aravind5@in.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* [release-branch.go1.20] cmd/compile: don't assume pointer of a slice is non-nilKeith Randall2023-03-295-3/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | unsafe.SliceData can return pointers which are nil. That function gets lowered to the SSA OpSlicePtr, which the compiler assumes is non-nil. This used to be the case as OpSlicePtr was only used in situations where the bounds check already passed. But with unsafe.SliceData that is no longer the case. There are situations where we know it is nil. Use Bounded() to indicate that. I looked through all the uses of OSPTR and added SetBounded where it made sense. Most OSPTR results are passed directly to runtime calls (e.g. memmove), so even if we know they are non-nil that info isn't helpful. Fixes #59296 Change-Id: I437a15330db48e0082acfb1f89caf8c56723fc51 Reviewed-on: https://go-review.googlesource.com/c/go/+/479896 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> (cherry picked from commit b899641ecea7d07c997282e985beb295c31d1097) Reviewed-on: https://go-review.googlesource.com/c/go/+/479899 Run-TryBot: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* [release-branch.go1.20] cmd/compile: re-compile instantiated generic methods ↵Cuong Manh Le2023-03-293-2/+26
| | | | | | | | | | | | | | | | | | | | | | in linkshared mode For G[T] that was seen and compiled in imported package, it is not added to typecheck.Target.Decls, prevent wasting compile time re-creating DUPOKS symbols. However, the linker do not support a type symbol referencing a method symbol across DSO boundary. That causes unreachable sym error when building under -linkshared mode. To fix it, always re-compile generic methods in linkshared mode. Fixes #59236 Change-Id: I894b417cfe8234ae1fe809cc975889345df22cef Reviewed-on: https://go-review.googlesource.com/c/go/+/477375 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/479355
* [release-branch.go1.20] time: fix timezone lookup logic for non-DST zonesGeon Kim2023-03-234-13/+24
| | | | | | | | | | | | | | | | | | | | | | | This change fixes time.LoadLocationFromTZData and time.Location.lookup logic if the given time is after the last transition and the extend string doesn't have the DST rule. For #58682 Fixes #59075 Change-Id: Ie34a6d658d14c2b33098b29ab83c041ef0d34266 GitHub-Last-Rev: f6681eb44c0ea0772004e56eb68fcbd9023d971e GitHub-Pull-Request: golang/go#58684 Reviewed-on: https://go-review.googlesource.com/c/go/+/471020 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> (cherry picked from commit 90dde5dec1126ddf2236730ec57511ced56a512d) Reviewed-on: https://go-review.googlesource.com/c/go/+/478658 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com>
* [release-branch.go1.20] cmd/link/internal/arm: fix off-by-1 in trampoline ↵Than McIntosh2023-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reachability computation Tweak the code in trampoline generation that determines if a given call branch will reach, changing the lower limit guard from "x < -0x800000" to "x <= -0x800000". This is to resolve linking failures when the computed displacement is exactly -0x800000, which results in errors of the form .../ld.gold: internal error in arm_branch_common, at ../../gold/arm.cc:4079 when using the Gold linker, and ...:(.text+0x...): relocation truncated to fit: R_ARM_CALL against `runtime.morestack_noctxt' when using the bfd linker. Fixes #59059. Updates #59034. Updates #58425. Change-Id: I8a76986b38727df1b961654824c2af23f06b9fcf Reviewed-on: https://go-review.googlesource.com/c/go/+/475957 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit f26bf203ac67fd917f2eb992baa1cb2d01edf3c8) Reviewed-on: https://go-review.googlesource.com/c/go/+/476936
* [release-branch.go1.20] cmd/go,cmd/link: prefer external linking when ↵Than McIntosh2023-03-179-15/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | strange cgo flags seen This patch changes the Go command to examine the set of compiler flags feeding into the C compiler when packages that use cgo are built. If any of a specific set of strange/dangerous flags are in use, then the Go command generates a token file ("preferlinkext") and embeds it into the compiled package's archive. When the Go linker reads the archives of the packages feeding into the link and detects a "preferlinkext" token, it will then use external linking for the program by default (although this default can be overridden with an explicit "-linkmode" flag). The intent here is to avoid having to teach the Go linker's host object reader to grok/understand the various odd symbols/sections/types that can result from boutique flag use, but rather to just boot the objects in question over to the C linker instead. Fixes #59051. Updates #58619. Updates #58620. Updates #58848. Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa Reviewed-on: https://go-review.googlesource.com/c/go/+/475375 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 035db07d7c5f1b90ebc9bae03cab694685acebb8) Reviewed-on: https://go-review.googlesource.com/c/go/+/476577
* [release-branch.go1.20] cmd/link: use label symbols for Duff's devices on ↵Cherry Mui2023-03-151-30/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | darwin/arm64 On darwin, the external linker generally supports CALL relocations with addend. One exception is that for a very large binary when it decides to insert a trampoline, instead of applying the addend to the call target (in the trampoline), it applies the addend to the CALL instruction in the caller, i.e. generating a call to trampoline+addend, which is not the correct address and usually points to unreloated functions. To work around this, we use label symbols so the CALL is targeting a label symbol without addend. To make things simple we always use label symbols for CALLs with addend (in external linking mode on darwin/arm64), even for small binaries. Updates #58935. Fixes #58954. Change-Id: I38aed6b62a0496c277c589b5accbbef6aace8dd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/474620 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> (cherry picked from commit 7dbd6de7d45da622e532e149de616e159286e1d4) Reviewed-on: https://go-review.googlesource.com/c/go/+/475175
* [release-branch.go1.20] Revert "cmd/compile: enable address folding for ↵Cherry Mui2023-03-152-132/+209
| | | | | | | | | | | | | | | | | | | | | global symbols of shared library" This reverts CL 445535. Reason for revert: see issue #58826. It doesn't handle large offset well. Updates #58826. Fixes #58920. Change-Id: Ic4a33f4c510c88628ea7e16207a60977a04cf798 Reviewed-on: https://go-review.googlesource.com/c/go/+/474175 Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> (cherry picked from commit a4cf4fde466035e6a485c29bd12450d51bc7d4e1) Reviewed-on: https://go-review.googlesource.com/c/go/+/474235 Reviewed-by: Keith Randall <khr@golang.org>
* [release-branch.go1.20] cmd/go: avoid running slow tests on non-longtest ↵Bryan C. Mills2023-03-091-36/+40
| | | | | | | | | | | | | | | | | | | | | | | | builders Also annotate calls to tooSlow with specific reasons. This will somewhat reduce test coverage on the 'darwin' builders until we have darwin 'longtest' builders (#35678,#49055), but still seems worthwhile to avoid alert fatigue from tests that really shouldn't be running in the short configurations. Updates #58918. Updates #58919. Fixes #58938. Change-Id: I0000f0084b262beeec3eca3e9b8a45d61fab4313 Reviewed-on: https://go-review.googlesource.com/c/go/+/474137 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 9f532dd0de78af91694a2d7e5e3c45b2978d1062) Reviewed-on: https://go-review.googlesource.com/c/go/+/474580
* [release-branch.go1.20] internal/testpty: fix error handlingHeschi Kreinick2023-03-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | When calling a c library function, you discover that an error has occurred, typically by looking at the return value of the function. Only after that can you use errno to figure out the cause of the error. Nothing about cgo changes that story -- you still have to look at the result before checking the error that represents errno. If not you can get false errors if the function happens to leak a non-zero errno. Fix testpty to check errors correctly. Fixes #58942. Change-Id: Idb95f8dd6a8ed63f653190c2e722e742cf50542b Reviewed-on: https://go-review.googlesource.com/c/go/+/463397 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit f85c282a18bbe7197ba645fff58ba5e0065962ca) Reviewed-on: https://go-review.googlesource.com/c/go/+/474616 Reviewed-by: Carlos Amedee <carlos@golang.org>
* [release-branch.go1.20] go1.20.2go1.20.2Gopher Robot2023-03-071-1/+1
| | | | | | | | | | Change-Id: Ib993bfea994a3e885a6068860d2e1f6705f8cf40 Reviewed-on: https://go-review.googlesource.com/c/go/+/474037 Auto-Submit: Gopher Robot <gobot@golang.org> Run-TryBot: Gopher Robot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.20] cmd/compile: relax overly strict assertionMatthew Dempsky2023-03-014-1/+48
| | | | | | | | | | | | | | | | | | | | | | | | | The assertion here was to make sure the newly constructed and typechecked expression selected the same receiver-qualified method, but in the case of anonymous receiver types we can actually end up with separate types.Field instances corresponding to each types.Type instance. In that case, the assertion spuriously failed. The fix here is to relax and assertion and just compare the method's name and type (including receiver type). Fixes #58776. Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886 Reviewed-on: https://go-review.googlesource.com/c/go/+/471676 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 37a2004b431df6cdd3260cbfe2ddb7673e94b9ef) Reviewed-on: https://go-review.googlesource.com/c/go/+/472620 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/x509: fix broken testsRoland Shoemaker2023-03-011-24/+34
| | | | | | | | | | | | | | | | | | | | | | Convert TestUnknownAuthorityError to use subtests, avoiding continuing the test after an unrecoverable failure. Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the behavior we were testing for. Also only enable the test on builders. Updates #58791 Updates #58812 Fixes #58811 Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f Reviewed-on: https://go-review.googlesource.com/c/go/+/472496 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit cf3d0655f8ca2de555549f6e8a91bf8654da7e6c) Reviewed-on: https://go-review.googlesource.com/c/go/+/472618 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/x509: fix system root tests + darwin ↵Roland Shoemaker2023-03-013-259/+238
| | | | | | | | | | | | | | | | | | | | | | intermediate handling On Windows, replace tests which rely on a root that expired last year. On Darwin fix an test which wasn't testing the expected behavior, and fix the behavior which was broken. Updates #58791 Fixes #58811 Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae Reviewed-on: https://go-review.googlesource.com/c/go/+/472295 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> (cherry picked from commit bb8f9a6ae66d742cb67b4ad444179905a537de00) Reviewed-on: https://go-review.googlesource.com/c/go/+/472616 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] syscall: fix invalid unsafe.Pointer conversion on ↵Cuong Manh Le2023-03-011-10/+13
| | | | | | | | | | | | | | | | | | | | | Windows Updates #58714 Fixes #58774 Change-Id: Ifa5c059ed5e358ed98aee7e83b95dd1806b535f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/471335 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com> (cherry picked from commit de8c999159bb72e8a43f9b38b6369fc43eca572e) Reviewed-on: https://go-review.googlesource.com/c/go/+/471599 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
* [release-branch.go1.20] net: delete TestTCPSelfConnectBryan C. Mills2023-03-011-44/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test is flaky, apparently due to a typo'd operator in CL 21447 that causes it to compare “same port OR IP” instead of “same port AND IP”. If we merely fixed the comparison, the test would hopefully stop being flaky itself, but we would still be left with another problem: repeatedly dialing a port that we believe to be unused can interfere with other tests, which may open the previously-unused port and then attempt a single Dial and expect it to succeed. Arbitrary other Dial calls for that port may cause the wrong connection to be accepted, leading to spurious test failures. Moreover, the test can be extremely expensive for the amount of data we hope to get from it, depending on the system's port-reuse algorithms and dial implementations. It is already scaled back by up to 1000x on a huge number of platforms due to latency, and may even be ineffective on those platforms because of the arbitrary 1ms Dial timeout. And the incremental value from it is quite low, too: it tests the workaround for what is arguably a bug in the Linux kernel, which ought to be fixed (and tested) upstream instead of worked around in every open-source project that dials local ports. Instead of trying to deflake this test, let's just get rid of it. Updates #18290. Fixes #58717. Change-Id: I8a58b93d67916a33741c9ab29ef99c49c46b32c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/460657 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> (cherry picked from commit e08642cae18460778ba3f7808c91cbf6d9ee9f67) Reviewed-on: https://go-review.googlesource.com/c/go/+/471155 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/x509: fix ParsePKCS8PrivateKey commentRoland Shoemaker2023-03-011-1/+1
| | | | | | | | | | | | | | | | | | | Updates #58789. Fixes #58793. Change-Id: I91cdd20c6d4f05baaacd6a38717aa7bed6682573 Reviewed-on: https://go-review.googlesource.com/c/go/+/472155 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit ec26277aecfba112089b1bb54b522bf062059e22) Reviewed-on: https://go-review.googlesource.com/c/go/+/472415 Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] syscall: Faccessat: check for CAP_DAC_OVERRIDE on LinuxKir Kolyshkin2023-02-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL 416115 added using faccessat2(2) from syscall.Faccessat on Linux (which is the only true way to implement AT_EACCESS flag handing), if available. If not available, it uses some heuristics to mimic the kernel behavior, mostly taken from glibc (see CL 126415). Next, CL 414824 added using the above call (via unix.Eaccess) to exec.LookPath in order to check if the binary can really be executed. As a result, in a very specific scenario, described below, syscall.Faccessat (and thus exec.LookPath) mistakenly tells that the binary can not be executed, while in reality it can be. This makes this bug a regression in Go 1.20. This scenario involves all these conditions: - no faccessat2 support available (i.e. either Linux kernel < 5.8, or a seccomp set up to disable faccessat2); - the current user is not root (i.e. geteuid() != 0); - CAP_DAC_OVERRIDE capability is set for the current process; - the file to be executed does not have executable permission bit set for either the current EUID or EGID; - the file to be executed have at least one executable bit set. Unfortunately, this set of conditions was observed in the wild -- a container run as a non-root user with the binary file owned by root with executable permission set for a user only [1]. Essentially it means it is not as rare as it may seem. Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the checks, so execve(2) and friends work the same was as for root user, i.e. if at least one executable bit it set, the permission to execute is granted (see generic_permission() function in the Linux kernel). Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel behavior for permission checks. [1] https://github.com/opencontainers/runc/issues/3715 For #58552. Fixes #58624. Change-Id: I82a7e757ab3fd3d0193690a65c3b48fee46ff067 Reviewed-on: https://go-review.googlesource.com/c/go/+/468735 Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit 031401a7905a38498fc399fc10cd0c1e885f7fc9) Reviewed-on: https://go-review.googlesource.com/c/go/+/469956 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/internal/bigmod: flag amd64 assembly as noescapeFilippo Valsorda2023-02-283-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I had forgotten, which caused amd64 allocations to go back up significantly. Added an allocations test. name old time/op new time/op delta DecryptPKCS1v15/2048-8 1.50ms ± 0% 1.48ms ± 0% -0.95% (p=0.000 n=9+10) DecryptPKCS1v15/3072-8 4.64ms ± 1% 4.60ms ± 0% -0.82% (p=0.000 n=8+10) DecryptPKCS1v15/4096-8 10.7ms ± 0% 10.6ms ± 1% -0.99% (p=0.000 n=10+10) EncryptPKCS1v15/2048-8 158µs ± 0% 157µs ± 0% -0.63% (p=0.000 n=10+10) DecryptOAEP/2048-8 1.50ms ± 0% 1.48ms ± 0% -1.09% (p=0.000 n=9+10) EncryptOAEP/2048-8 161µs ± 0% 160µs ± 0% -0.34% (p=0.000 n=9+10) SignPKCS1v15/2048-8 1.55ms ± 0% 1.53ms ± 1% -1.32% (p=0.000 n=10+10) VerifyPKCS1v15/2048-8 157µs ± 0% 157µs ± 0% -0.33% (p=0.004 n=9+10) SignPSS/2048-8 1.55ms ± 0% 1.54ms ± 0% -1.14% (p=0.000 n=10+10) VerifyPSS/2048-8 160µs ± 0% 160µs ± 0% -0.32% (p=0.000 n=10+10) name old alloc/op new alloc/op delta DecryptPKCS1v15/2048-8 15.0kB ± 0% 0.6kB ± 0% -95.74% (p=0.000 n=10+10) DecryptPKCS1v15/3072-8 17.9kB ± 0% 3.5kB ± 0% -80.65% (p=0.000 n=10+10) DecryptPKCS1v15/4096-8 19.1kB ± 0% 4.7kB ± 0% -75.25% (p=0.000 n=10+10) EncryptPKCS1v15/2048-8 7.51kB ± 0% 1.17kB ± 0% -84.39% (p=0.000 n=10+10) DecryptOAEP/2048-8 15.3kB ± 0% 0.9kB ± 0% -94.29% (p=0.000 n=10+10) EncryptOAEP/2048-8 7.74kB ± 0% 1.40kB ± 0% -81.86% (p=0.000 n=10+10) SignPKCS1v15/2048-8 21.6kB ± 0% 0.9kB ± 0% -95.86% (p=0.000 n=10+10) VerifyPKCS1v15/2048-8 7.25kB ± 0% 0.91kB ± 0% -87.42% (p=0.000 n=10+10) SignPSS/2048-8 22.0kB ± 0% 1.3kB ± 0% -94.12% (p=0.000 n=10+10) VerifyPSS/2048-8 7.46kB ± 0% 1.12kB ± 0% -84.98% (p=0.000 n=10+10) name old allocs/op new allocs/op delta DecryptPKCS1v15/2048-8 54.0 ± 0% 4.0 ± 0% -92.59% (p=0.000 n=10+10) DecryptPKCS1v15/3072-8 60.0 ± 0% 10.0 ± 0% -83.33% (p=0.000 n=10+10) DecryptPKCS1v15/4096-8 60.0 ± 0% 10.0 ± 0% -83.33% (p=0.000 n=10+10) EncryptPKCS1v15/2048-8 29.0 ± 0% 7.0 ± 0% -75.86% (p=0.000 n=10+10) DecryptOAEP/2048-8 60.0 ± 0% 10.0 ± 0% -83.33% (p=0.000 n=10+10) EncryptOAEP/2048-8 35.0 ± 0% 13.0 ± 0% -62.86% (p=0.000 n=10+10) SignPKCS1v15/2048-8 77.0 ± 0% 5.0 ± 0% -93.51% (p=0.000 n=10+10) VerifyPKCS1v15/2048-8 28.0 ± 0% 6.0 ± 0% -78.57% (p=0.000 n=10+10) SignPSS/2048-8 82.0 ± 0% 10.0 ± 0% -87.80% (p=0.000 n=10+10) VerifyPSS/2048-8 33.0 ± 0% 11.0 ± 0% -66.67% (p=0.000 n=10+10) Updates #58501. Fixes #58505. Change-Id: I418c5152833787b80220b556336ec284674c2493 Reviewed-on: https://go-review.googlesource.com/c/go/+/460542 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> (cherry picked from commit ed370d8720750ad670564079b1e0bcf74f75dd3a) Reviewed-on: https://go-review.googlesource.com/c/go/+/471855 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] crypto/ecdh: explicitly reject mismatched curves in ECDHRoland Shoemaker2023-02-282-1/+42
| | | | | | | | | | | | | | | | | | | | | | | Return an explicit error when PrivateKey.ECDH is called with a PublicKey which uses a different Curve. Also document this requirement, even though it is perhaps obvious. Updates #58131. Fixes #58498. Change-Id: I739181a3f1283bed14fb5ee7eb78658b854d28d8 Reviewed-on: https://go-review.googlesource.com/c/go/+/464335 Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> (cherry picked from commit 67d8916d551d22f5376e0be71d3922c9d63eaa6a) Reviewed-on: https://go-review.googlesource.com/c/go/+/471602 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
* [release-branch.go1.20] cmd/compile/internal/noder: correct positions for ↵Matthew Dempsky2023-02-282-18/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | synthetic closures When inlining functions that contain function literals, we need to be careful about position information. The OCLOSURE node should use the inline-adjusted position, but the ODCLFUNC and its body should use the original positions. However, the same problem can arise with certain generic constructs, which require the compiler to synthesize function literals to insert dictionary arguments. go.dev/cl/425395 fixed the issue with user-written function literals in a somewhat kludgy way; this CL extends the same solution to synthetic function literals. This is all quite subtle and the solutions aren't terribly robust, so longer term it's probably desirable to revisit how we track inlining context for positions. But for now, this seems to be the least bad solution, esp. for backporting to 1.20. Updates #54625. Fixes #58531. Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/468415 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> (cherry picked from commit 873c14cec730ee278848f7cc58d2b4d89ab52288) Reviewed-on: https://go-review.googlesource.com/c/go/+/471677 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.20] cmd/link: better fix for arm32 trampgen problem with ↵Than McIntosh2023-02-271-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | duff routines This patch provides a fix for a problem linking large arm32 binaries with external linking, specifically R_CALLARM relocations against runtime.duff* routines being flagged by the external linker as not reaching. What appears to be happening in the bug in question is that the Go linker and the external linker are using slightly different recipes to decide whether a given R_CALLARM relocation will "fit" (e.g. will not require a trampoline). The Go linker is taking into account the addend on the call reloc (which for calls to runtime.duffcopy or runtime.duffzero is nonzero), whereas the external linker appears to be ignoring the addend. Example to illustrate: Addr Size Func ----- ----- ----- ... XYZ 1024 runtime.duffcopy ... ABC ... mypackge.MyFunc + R0: R_CALLARM o=8 a=848 tgt=runtime.duffcopy<0> Let's say that the distance between ABC (start address of runtime.duffcopy) and XYZ (start of MyFunc) is just over the architected 24-bit maximum displacement for an R_CALLARM (let's say that ABC-XYZ is just over the architected limit by some small value, say 36). Because we're calling into runtime.duffcopy at offset 848, however, the relocation does in fact fit, but if the external linker isn't taking into account the addend (assuming that all calls target the first instruction of the called routine), then we'll get a "doesn't fit" error from the linker. To work around this problem, revise the ARM trampoline generation code in the Go linker that computes the trampoline threshold to ignore the addend on R_CALLARM relocations, so as to harmonize the two linkers. Fixes #58503. Updates #58428. Updates #58425. Change-Id: I56e580c05b7b47bbe8edf5532a1770bbd700fbe5 Reviewed-on: https://go-review.googlesource.com/c/go/+/469275 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> (cherry picked from commit 0b5affb193ed559f2cb646e0324827f261e2e767) Reviewed-on: https://go-review.googlesource.com/c/go/+/471597
* [release-branch.go1.20] crypto/internal/nistec: reduce P-256 scalarFilippo Valsorda2023-02-273-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike the rest of nistec, the P-256 assembly doesn't use complete addition formulas, meaning that p256PointAdd[Affine]Asm won't return the correct value if the two inputs are equal. This was (undocumentedly) ignored in the scalar multiplication loops because as long as the input point is not the identity and the scalar is lower than the order of the group, the addition inputs can't be the same. As part of the math/big rewrite, we went however from always reducing the scalar to only checking its length, under the incorrect assumption that the scalar multiplication loop didn't require reduction. Added a reduction, and while at it added it in P256OrdInverse, too, to enforce a universal reduction invariant on p256OrdElement values. Note that if the input point is the infinity, the code currently still relies on undefined behavior, but that's easily tested to behave acceptably, and will be addressed in a future CL. Updates #58647 Fixes #58720 Fixes CVE-2023-24532 (Filed with the "safe APIs like complete addition formulas are good" dept.) Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24 Reviewed-on: https://go-review.googlesource.com/c/go/+/471255 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 203e59ad41bd288e1d92b6f617c2f55e70d3c8e3) Reviewed-on: https://go-review.googlesource.com/c/go/+/471695 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org>
* [release-branch.go1.20] cmd/internal/cov: fix misuse of bufio.Reader.Read in ↵Than McIntosh2023-02-224-1/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | read helper Fix a misuse of bufio.Reader.Read in the helper class cmd/internal/cov.MReader; the MReader method in question should have been using io.ReadFull (passing the bufio.Reader) instead of directly calling Read. Using the Read method instead of io.ReadFull will result in a "short" read when processing a specific subset of counter data files, e.g. those that are short enough to not trigger the mmap-based scheme we use for larger files, but also with a large args section (something large enough to exceed the default 4k buffer size used by bufio.Reader). Along the way, add some additional defered Close() calls for files opened by the CovDataReader.visitPod, to enure we don't leave any open file descriptor following a call to CovDataReader.Visit. Fixes #58427. Updates #58411. Change-Id: Iea48dc25c0081be1ade29f3a633df02a681fd941 Reviewed-on: https://go-review.googlesource.com/c/go/+/466677 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit a7fe9ada10c02a7ea61b2909ef7db151d290073f) Reviewed-on: https://go-review.googlesource.com/c/go/+/468536 Reviewed-by: Cherry Mui <cherryyz@google.com>
* [release-branch.go1.20] Revert "internal/poll: drop redundant ENOSYS in ↵Ian Lance Taylor2023-02-221-10/+14
| | | | | | | | | | | | | | | | | | | CopyFileRange" This reverts CL 428555. Reason for revert: It appears that even a newer kernel can get ENOSYS from copy_file_range. For #58592 Fixes #58627 Change-Id: Ib8dd1be61544f54bf652a99dc0b449109f8f50ed Reviewed-on: https://go-review.googlesource.com/c/go/+/470316 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.20] runtime: check for overflow in sweep assistMichael Anthony Knyszek2023-02-151-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sweep assist computation is intentionally racy for performance, since the specifics of sweep assist aren't super sensitive to error. However, if overflow occurs when computing the live heap delta, we can end up with a massive sweep target that causes the sweep assist to sweep until sweep termination, causing severe latency issues. In fact, because heapLive doesn't always increase monotonically then anything that flushes mcaches will cause _all_ allocating goroutines to inevitably get stuck in sweeping. Consider the following scenario: 1. SetGCPercent is called, updating sweepHeapLiveBasis to heapLive. 2. Very shortly after, ReadMemStats is called, flushing mcaches and decreasing heapLive below the value sweepHeapLiveBasis was set to. 3. Every allocating goroutine goes to refill its mcache, calls into deductSweepCredit for sweep assist, and gets stuck sweeping until the sweep phase ends. Fix this by just checking for overflow in the delta live heap calculation and if it would overflow, pick a small delta live heap. This probably means that no sweeping will happen at all, but that's OK. This is a transient state and the runtime will recover as soon as heapLive increases again. Note that deductSweepCredit doesn't check overflow on other operations but that's OK: those operations are signed and extremely unlikely to overflow. The subtraction targeted by this CL is only a problem because it's unsigned. An alternative fix would be to make the operation signed, but being explicit about the overflow situation seems worthwhile. For #57523. Fixes #58536. Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215 Reviewed-on: https://go-review.googlesource.com/c/go/+/468375 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
View Lorry Controller Status