summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [release-branch.go1.19] cmd/compile: fix bswap/load rewrite rulesrelease-branch.go1.19Keith 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 #59974 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> Reviewed-on: https://go-review.googlesource.com/c/go/+/492697 TryBot-Bypass: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com>
* [release-branch.go1.19] go1.19.9go1.19.9Gopher Robot2023-05-021-1/+1
| | | | | | | | | Change-Id: Ib6c0fa04bf59bfaae8081927059b4860dfcf6d21 Reviewed-on: https://go-review.googlesource.com/c/go/+/491436 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Carlos Amedee <carlos@golang.org>
* [release-branch.go1.19] 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 #59815 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/+/1851498 Reviewed-by: Roland Shoemaker <bracewell@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491357 Run-TryBot: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] 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 #59813 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/+/1851497 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491355 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Bypass: Carlos Amedee <carlos@golang.org> Run-TryBot: Carlos Amedee <carlos@golang.org>
* [release-branch.go1.19] 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 #59811 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/+/1851496 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/491335 Run-TryBot: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] 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 #59539. 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/+/488075 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
* [release-branch.go1.19] 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 #59373 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> Reviewed-on: https://go-review.googlesource.com/c/go/+/483177 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] syscall: restore original NOFILE rlimit in child processIan Lance Taylor2023-04-1465-89/+381
| | | | | | | | | | | | | | | | | | | | | | 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 #59063 Change-Id: I9be6ecc52d4f82eb226907611aec9df808e1da84 Reviewed-on: https://go-review.googlesource.com/c/go/+/478660 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
* [release-branch.go1.19] 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 #59579 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/+/484135 Run-TryBot: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.19] 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 #59269. Updates #59234. For #59271. Change-Id: I25f4d8245da3301dccccfb44da8ff1a5985392a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/482535 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.19] cmd/compile: defer transitive inlining until after ↵Michael Knyszek2023-04-052-30/+65
| | | | | | | | | | | | | | | | | | | | | | | AST is edited This CL changes the inliner to process transitive inlining iteratively after the AST has actually been edited, rather than recursively and immediately. This is important for handling indirect function calls correctly, because ir.reassigned walks the function body looking for reassignments; whereas previously the inlined reassignments might not have been actually added to the AST yet. Fixes #59158. This change was previously reverted as CL 481796 because the branch was frozen for release. Change-Id: I97fcd32956cc1349d87a92066e8559cb90da73b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/481797 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
* [release-branch.go1.19] go1.19.8go1.19.8Gopher Robot2023-04-041-1/+1
| | | | | | | | | | Change-Id: If779869c8f3357fbf5df28bdb2640b183e608f46 Reviewed-on: https://go-review.googlesource.com/c/go/+/482098 Auto-Submit: Gopher Robot <gobot@golang.org> Run-TryBot: Gopher Robot <gobot@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.19] html/template: disallow actions in JS template literalsRoland Shoemaker2023-04-049-33/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #59271 [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 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/+/1802612 Run-TryBot: Roland Shoemaker <bracewell@google.com> Change-Id: Ic7f10595615f2b2740d9c85ad7ef40dc0e78c04c Reviewed-on: https://go-review.googlesource.com/c/go/+/481987 Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.19] 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 Fixes #59273 For #59180 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> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802611 Reviewed-by: Damien Neil <dneil@google.com> Change-Id: Ifdfa192d54f722d781a4d8c5f35b5fb72d122168 Reviewed-on: https://go-review.googlesource.com/c/go/+/481986 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.19] mime/multipart: limit parsed mime message sizesDamien Neil2023-04-045-17/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #59269 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/+/1801087 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Change-Id: If134890d75f0d95c681d67234daf191ba08e6424 Reviewed-on: https://go-review.googlesource.com/c/go/+/481985 Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.19] 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 #59269 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> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802396 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Change-Id: I31bc50e9346b4eee6fbe51a18c3c57230cc066db Reviewed-on: https://go-review.googlesource.com/c/go/+/481984 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com>
* [release-branch.go1.19] 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 #59269 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> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802395 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Change-Id: Ie405470c92abffed3356913b37d813e982c96c8b Reviewed-on: https://go-review.googlesource.com/c/go/+/481983 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* [release-branch.go1.19] 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 #59267 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> (cherry picked from commit f739f080a72fd5b06d35c8e244165159645e2ed6) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1802393 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Change-Id: I675451438d619a9130360c56daf529559004903f Reviewed-on: https://go-review.googlesource.com/c/go/+/481982 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
* Revert "[release-branch.go1.19] cmd/compile: defer transitive inlining until ↵Michael Knyszek2023-04-032-65/+30
| | | | | | | | | | | | | | | | after AST is edited" This reverts commit 837b1314fde57c0afad96bbfa050b47ce304c204. Reason for revert: The branch is currently frozen for the release. Change-Id: I800e241b8676564ea893ae673d407b41e55f0473 Reviewed-on: https://go-review.googlesource.com/c/go/+/481796 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com>
* [release-branch.go1.19] cmd/compile: defer transitive inlining until after ↵Matthew Dempsky2023-04-032-30/+65
| | | | | | | | | | | | | | | | | | | | | | | AST is edited This CL changes the inliner to process transitive inlining iteratively after the AST has actually been edited, rather than recursively and immediately. This is important for handling indirect function calls correctly, because ir.reassigned walks the function body looking for reassignments; whereas previously the inlined reassignments might not have been actually added to the AST yet. Fixes #59158. Change-Id: I0dd69813c8a70b965174e0072335bc00afedf286 Reviewed-on: https://go-review.googlesource.com/c/go/+/425257 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit f983a9340d5660a9655b63a371966b5df69be8c5) Reviewed-on: https://go-review.googlesource.com/c/go/+/479629 Reviewed-by: Heschi Kreinick <heschi@google.com>
* [release-branch.go1.19] 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 #59219 Change-Id: Ieb77b2afa8fb4e6f3943df5ce138679f6750d376 Reviewed-on: https://go-review.googlesource.com/c/go/+/479628 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] 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 #59074 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/+/478657 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com>
* [release-branch.go1.19] 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 #59058. 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/+/476935
* [release-branch.go1.19] cmd/go,cmd/link: prefer external linking when ↵Than McIntosh2023-03-178-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 #59050. 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/+/476576
* [release-branch.go1.19] runtime/pprof: improve output of TestLabelSystemstackAustin Clements2023-03-151-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current output of TestLabelSystemstack is a bit cryptic. This CL improves various messages and hopefully simplifies the logic in the test. Simplifying the logic leads to three changes in possible outcomes, which I verified by running the logic before and after this change through all 2^4 possibilities (https://go.dev/play/p/bnfb-OQCT4j): 1. If a sample both must be labeled and must not be labeled, the test now reports that explicitly rather than giving other confusing output. 2. If a sample must not be labeled but is, the current logic will print two identical error messages. The new logic prints only one. 3. If the test finds no frames at all that it recognizes, but the sample is labeled, it will currently print a confusing "Sample labeled got true want false" message. The new logic prints nothing. We've seen this triggered by empty stacks in profiles. Fixes #51550. This bug was caused by case 3 above, where it was triggered by a profile label on an empty stack. It's valid for empty stacks to appear in a profile if we sample a goroutine just as it's exiting (and that goroutine may have a profile label), so the test shouldn't fail in this case. For #58939. Change-Id: I1593ec4ac33eced5bb89572a3ba7623e56f2fb3d Reviewed-on: https://go-review.googlesource.com/c/go/+/460516 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit d9f23cfe78eadcdbde31fd931e90bebb72455648) Reviewed-on: https://go-review.googlesource.com/c/go/+/474618 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* [release-branch.go1.19] cmd/go: avoid running slow tests on non-longtest ↵Bryan C. Mills2023-03-091-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | 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 #58937. 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/+/474581
* [release-branch.go1.19] os/signal/internal/pty: 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 #58941 Change-Id: I4009e10b344e43fec291b941a63bcf4548937d44 Reviewed-on: https://go-review.googlesource.com/c/go/+/474619 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] go1.19.7go1.19.7Gopher Robot2023-03-071-1/+1
| | | | | | | | | | | Change-Id: Iad8c5261b54d0a160ec6037d877b8655535149fa Reviewed-on: https://go-review.googlesource.com/c/go/+/474038 Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Bypass: Carlos Amedee <carlos@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Run-TryBot: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] 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 #58810 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/+/472617 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] 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 #58810 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/+/472615 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] syscall: fix invalid unsafe.Pointer conversion on ↵Cuong Manh Le2023-03-011-10/+14
| | | | | | | | | | | | | | | | | | | Windows This cherry-pick CL 471335 without using unsafe.{Add,Slice}. Fixes #58773 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> Reviewed-on: https://go-review.googlesource.com/c/go/+/471935 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] 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 #58716. 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/+/471156 Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] 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 #58502. 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/+/471598
* [release-branch.go1.19] 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 #58719 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/+/471696 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
* [release-branch.go1.19] 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 #58535. Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215 Reviewed-on: https://go-review.googlesource.com/c/go/+/468376 Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] runtime: fix signature for linked functionsAdin Scannell2023-02-152-2/+2
| | | | | | | | | | | | | | | | | | These functions are linked using go:linkname, but do not match the original declarations. This change brings these in sync. For #58441. Change-Id: I16651304c3dba2f9897c2c42e30555d2f7805c2a Reviewed-on: https://go-review.googlesource.com/c/go/+/466615 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com> (cherry picked from commit 8fb9565832e6dbacaaa057ffabc251a9341f8d23) Reviewed-on: https://go-review.googlesource.com/c/go/+/466858 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
* [release-branch.go1.19] all: update vendored golang.org/x/netMichael Pratt2023-02-144-6/+4
| | | | | | | | | | | | | | | | | | | Update golang.org/x/net to the tip of internal-branch.go1.19-vendor to include CL 468335. The contents of that CL were already merged into this branch in CL 468118, so this CL just brings go.mod back in line to matching the actual vendored content. For #58355 For #57855 Change-Id: Ie952744a5b2249f0c05afb7f86bebf872734b09a Reviewed-on: https://go-review.googlesource.com/c/go/+/468303 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
* [release-branch.go1.19] go1.19.6go1.19.6Gopher Robot2023-02-141-1/+1
| | | | | | | | | | Change-Id: Iaafff862e746e7c81a6df9ca9b7b6179efe1172e Reviewed-on: https://go-review.googlesource.com/c/go/+/468237 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] net/http: update bundled golang.org/x/net/http2Roland Shoemaker2023-02-142-31/+50
| | | | | | | | | | | | | | | | | | | | | Disable cmd/internal/moddeps test, since this update includes PRIVATE track fixes. Fixes CVE-2022-41723 Fixes #58355 Updates #57855 Change-Id: Ie870562a6f6e44e4e8f57db6a0dde1a41a2b090c Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728939 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468118 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
* [release-branch.go1.19] crypto/tls: replace all usages of BytesOrPanicRoland Shoemaker2023-02-1413-503/+657
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Message marshalling makes use of BytesOrPanic a lot, under the assumption that it will never panic. This assumption was incorrect, and specifically crafted handshakes could trigger panics. Rather than just surgically replacing the usages of BytesOrPanic in paths that could panic, replace all usages of it with proper error returns in case there are other ways of triggering panics which we didn't find. In one specific case, the tree routed by expandLabel, we replace the usage of BytesOrPanic, but retain a panic. This function already explicitly panicked elsewhere, and returning an error from it becomes rather painful because it requires changing a large number of APIs. The marshalling is unlikely to ever panic, as the inputs are all either fixed length, or already limited to the sizes required. If it were to panic, it'd likely only be during development. A close inspection shows no paths for a user to cause a panic currently. This patches ends up being rather large, since it requires routing errors back through functions which previously had no error returns. Where possible I've tried to use helpers that reduce the verbosity of frequently repeated stanzas, and to make the diffs as minimal as possible. Thanks to Marten Seemann for reporting this issue. Updates #58001 Fixes #58358 Fixes CVE-2022-41724 Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436 Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 0f3a44ad7b41cc89efdfad25278953e17d9c1e04) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728204 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468117 Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* [release-branch.go1.19] mime/multipart: limit memory/inode consumption of ↵Damien Neil2023-02-146-38/+295
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ReadForm Reader.ReadForm is documented as storing "up to maxMemory bytes + 10MB" in memory. Parsed forms can consume substantially more memory than this limit, since ReadForm does not account for map entry overhead and MIME headers. In addition, while the amount of disk memory consumed by ReadForm can be constrained by limiting the size of the parsed input, ReadForm will create one temporary file per form part stored on disk, potentially consuming a large number of inodes. Update ReadForm's memory accounting to include part names, MIME headers, and map entry overhead. Update ReadForm to store all on-disk file parts in a single temporary file. Files returned by FileHeader.Open are documented as having a concrete type of *os.File when a file is stored on disk. The change to use a single temporary file for all parts means that this is no longer the case when a form contains more than a single file part stored on disk. The previous behavior of storing each file part in a separate disk file may be reenabled with GODEBUG=multipartfiles=distinct. Update Reader.NextPart and Reader.NextRawPart to set a 10MiB cap on the size of MIME headers. Thanks to Jakob Ackermann (@das7pad) for reporting this issue. Updates #58006 Fixes #58362 Fixes CVE-2022-41725 Change-Id: Ibd780a6c4c83ac8bcfd3cbe344f042e9940f2eab Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1714276 Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit ed4664330edcd91b24914c9371c377c132dbce8c) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728949 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468116 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
* [release-branch.go1.19] path/filepath: do not Clean("a/../c:/b") into c:\b ↵Damien Neil2023-02-143-14/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on Windows Do not permit Clean to convert a relative path into one starting with a drive reference. This change causes Clean to insert a . path element at the start of a path when the original path does not start with a volume name, and the first path element would contain a colon. This may introduce a spurious but harmless . path element under some circumstances. For example, Clean("a/../b:/../c") becomes `.\c`. This reverts CL 401595, since the change here supersedes the one in that CL. Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue. Updates #57274 Fixes #57275 Fixes CVE-2022-41722 Change-Id: I837446285a03aa74c79d7642720e01f354c2ca17 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1675249 Reviewed-by: Roland Shoemaker <bracewell@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> (cherry picked from commit 780dfa043ff5192c37de0d6fd1053a66b2b9f378) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728206 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468115 Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Bypass: Michael Pratt <mpratt@google.com>
* [release-branch.go1.19] cmd/link: keep go.buildinfo even with --gc-sectionsRuss Cox2023-02-102-1/+36
| | | | | | | | | | | | | | | | | | | | | | If you use an external linker with --gc-sections, nothing refers to .go.buildinfo, so the section is deleted, which in turns makes 'go version' fail on the binary. It is important for vulnerability scanning and the like to be able to run 'go version' on any binary. Fix this by inserting a reference to .go.buildinfo from the rodata section, which will not be GC'ed. Fixes #58222. Fixes #58223. Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123 Reviewed-on: https://go-review.googlesource.com/c/go/+/464435 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/464795
* [release-branch.go1.19] cmd/go: remove tests that assume lack of new ↵Bryan C. Mills2023-02-101-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | | versions of external modules In general it seems ok to assume that an open-source module that did exist will continue to do so — after all, users of open-source modules already do that all the time. However, we should not assume that those modules do not publish new versions — that's really up to their maintainers to decide. Two existing tests did make that assumption for the module gopkg.in/natefinch/lumberjack.v2. Let's remove those two tests. If we need to replace them at some point, we can replace them with hermetic test-only modules (#54503) or perhaps modules owned by the Go project. Updates #58445. Fixes #58449. Change-Id: Ica8fe587d86fc41f3d8445a4cd2b8820455ae45f Reviewed-on: https://go-review.googlesource.com/c/go/+/466862 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* [release-branch.go1.19] cmd/go: skip test cases that depend on gopkg.inBryan C. Mills2023-02-092-1/+11
| | | | | | | | | | | | | | | | Updates #54503. Change-Id: Ie13d028b09260d2d316c343b3ea812bb9cce4e6d Reviewed-on: https://go-review.googlesource.com/c/go/+/424594 Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> (cherry picked from commit c7f870ebc41029e07e7ffd8ff2d96b91fd83cd40) Reviewed-on: https://go-review.googlesource.com/c/go/+/466857 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
* [release-branch.go1.19] time: update windows zoneinfo_abbrsqmuntal2023-02-091-14/+16
| | | | | | | | | | | | | | | | | | | | | zoneinfo_abbrs hasn't been updated since go 1.14, it's time to regenerate it. Fixes #58118. Change-Id: Ic156ae607c46f1f5a9408b1fc0b56de6c14a4ed4 Reviewed-on: https://go-review.googlesource.com/c/go/+/463838 Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit 007d8f4db1f890f0d34018bb418bdc90ad4a8c35) Reviewed-on: https://go-review.googlesource.com/c/go/+/466555 TryBot-Bypass: David Chase <drchase@google.com> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
* [release-branch.go1.19] net/http: accept HEAD requests with a bodyDamien Neil2023-01-304-23/+85
| | | | | | | | | | | | | | | | | | | | | | | RFC 7231 permits HEAD requests to contain a body, although it does state there are no defined semantics for payloads of HEAD requests and that some servers may reject HEAD requests with a payload. Accept HEAD requests with a body. Fix a bug where a HEAD request with a chunked body would interpret the body as the headers for the next request on the connection. For #53960. For #56154. Change-Id: I83f7112fdedabd6d6291cd956151d718ee6942cd Reviewed-on: https://go-review.googlesource.com/c/go/+/418614 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/457438 Reviewed-by: Than McIntosh <thanm@google.com>
* [release-branch.go1.19] runtime: fix performance regression in ↵Archana R2023-01-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | morestack_noctxt on ppc64 In the fix for 54332 the MOVD R1, R1 instruction was added to morestack_noctxt function to set the SPWRITE bit. However, the instruction MOVD R1, R1 results in or r1,r1,r1 which is a special instruction on ppc64 architecture as it changes the thread priority and can negatively impact performance in some cases. More details on such similar nops can be found in Power ISA v3.1 Book II on Power ISA Virtual Environment architecture in the chapter on Program Priority Registers and Or instructions. Replacing this by OR R0, R1 has the same affect on setting SPWRITE as needed by the first fix but does not affect thread priority and hence does not cause the degradation in performance Hash65536-64 2.81GB/s ±10% 16.69GB/s ± 0% +494.44% Fixes #57812 Change-Id: Ib912e3716c6afd277994d6c1c5b2891f82225d50 Reviewed-on: https://go-review.googlesource.com/c/go/+/461597 Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Auto-Submit: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> (cherry picked from commit 1c65b69bd1dbc930c6246877f6c21c81f2a60d55) Reviewed-on: https://go-review.googlesource.com/c/go/+/462335 Run-TryBot: Archana Ravindar <aravind5@in.ibm.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* [release-branch.go1.19] crypto/x509: reduce boring test key sizeRoland Shoemaker2023-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | Generating 8192 bit keys times out on builders relatively frequently. We just need something that isn't a boringAllowCert allowed key size so we can test that a non-boringAllowCert signed intermediate works, so just use 512 instead since it'll be significantly faster. Fixes #57635 Updates #56798 Change-Id: I416e0d8c3aa11ff44e9870755efa95c74d1013f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/451656 Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> (cherry picked from commit 38b9ff60071fc40d197e7002db1320539e74a678) Reviewed-on: https://go-review.googlesource.com/c/go/+/461615 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
* [release-branch.go1.19] go1.19.5go1.19.5Gopher Robot2023-01-101-1/+1
| | | | | | | | | | Change-Id: I29de2897f400f576dfde497b4c51f7ee04696b36 Reviewed-on: https://go-review.googlesource.com/c/go/+/461358 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Run-TryBot: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Auto-Submit: Gopher Robot <gobot@golang.org>
View Lorry Controller Status