go, branch go1.11.13

[release-branch.go1.11-security] go1.11.13

2019-08-13T16:26:07Z

Change-Id: Idf5f9d00388b0da77f2c2ce3650eb65271bd9e68 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526996 Reviewed-by: Filippo Valsorda

[release-branch.go1.11-security] doc: document Go 1.11.13

2019-08-13T14:43:54Z

Change-Id: I0daab6cd347e1fc0066e516f02c33f1b63e3f1a3 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526992 Reviewed-by: Filippo Valsorda (cherry picked from commit 685bfb1adec3d9fcb589f35eb2bc0b99d2f84bf0) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526994

[release-branch.go1.11-security] net/url: make Hostname and Port predictable for invalid Host values

2019-08-13T00:21:41Z

When Host is not valid per RFC 3986, the behavior of Hostname and Port was wildly unpredictable, to the point that Host could have a suffix that didn't appear in neither Hostname nor Port. This is a security issue when applications are applying checks to Host and expecting them to be meaningful for the contents of Hostname. To reduce disruption, this change only aims to guarantee the following two security-relevant invariants. * Host is either Hostname or [Hostname] with Port empty, or Hostname:Port or [Hostname]:Port. * Port is only decimals. The second invariant is the one that's most likely to cause disruption, but I believe it's important, as it's conceivable an application might do a suffix check on Host and expect it to be meaningful for the contents of Hostname (if the suffix is not a valid port). There are three ways to ensure it. 1) Reject invalid ports in Parse. Note that non-numeric ports are already rejected if and only if the host starts with "[". 2) Consider non-numeric ports as part of Hostname, not Port. 3) Allow non-numeric ports, and hope they only flow down to net/http, which will reject them (#14353). This change adopts both 1 and 2. We could do only the latter, but then these invalid hosts would flow past port checks, like in http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully supported anyway, because they were rejected after IPv6 literals, so this restores consistency. We could do only the former, but at this point 2) is free and might help with manually constructed Host values (or if we get something wrong in Parse). Note that net.SplitHostPort and net.Dial explicitly accept service names in place of port numbers, but this is an URL package, and RFC 3986, Section 3.2.3, clearly specifies ports as a number in decimal. net/http uses a mix of net.SplitHostPort and url.Parse that would deserve looking into, but in general it seems that it will still accept service names in Addr fields as they are passed to net.Listen, while rejecting them in URLs, which feels correct. This leaves a number of invalid URLs to reject, which however are not security relevant once the two invariants above hold, so can be done in Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals, hostnames with invalid characters, and more. Tested with 200M executions of go-fuzz and the following Fuzz function. u, err := url.Parse(string(data)) if err != nil { return 0 } h := u.Hostname() p := u.Port() switch u.Host { case h + ":" + p: return 1 case "[" + h + "]:" + p: return 1 case h: fallthrough case "[" + h + "]": if p != "" { panic("unexpected Port()") } return 1 } panic("Host is not a variant of [Hostname]:Port") Fixes CVE-2019-14809 Updates #29098 Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895 Reviewed-on: https://go-review.googlesource.com/c/go/+/189258 Reviewed-by: Ian Lance Taylor (cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408 Reviewed-by: Dmitri Shuralyov (cherry picked from commit 3226f2d492963d361af9dfc6714ef141ba606713) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526409

[release-branch.go1.11-security] net/http: update bundled http2 to import security fix

2019-08-12T21:44:25Z

Apply the following unpublished golang.org/x/net commit. commit b1cc14aba47abf96f96818003fa4caad3a4b4e86 Author: Filippo Valsorda Date: Sun Aug 11 02:12:18 2019 -0400 [release-branch.go1.11] http2: limit number of control frames in server send queue An attacker could cause servers to queue an unlimited number of PING ACKs or RST_STREAM frames by soliciting them and not reading them, until the program runs out of memory. Limit control frames in the queue to a few thousands (matching the limit imposed by other vendors) by counting as they enter and exit the scheduler, so the protection will work with any WriteScheduler. Once the limit is exceeded, close the connection, as we have no way to communicate with the peer. Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526070 Reviewed-by: Dmitri Shuralyov Fixes CVE-2019-9512 and CVE-2019-9514 Updates #33606 Change-Id: Iecedf1cc63ec7a1cd75661ec591d91ebc911cc64 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526072 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.11] go1.11.12

2019-07-08T19:49:55Z

Change-Id: I7d61b51d4b1b522315370bd17483feab24a2c7bb Reviewed-on: https://go-review.googlesource.com/c/go/+/185260 Reviewed-by: Dmitri Shuralyov Run-TryBot: Alexander Rakoczy TryBot-Result: Gobot Gobot

[release-branch.go1.11] doc: document Go 1.11.12

2019-07-08T18:37:13Z

Change-Id: I1b2e369befc58b3f88ac201442a2d9f76d87d54e Reviewed-on: https://go-review.googlesource.com/c/go/+/185257 Reviewed-by: Dmitri Shuralyov (cherry picked from commit 0fddd668671c44a622be7d7ea71962be644d8218) Reviewed-on: https://go-review.googlesource.com/c/go/+/185143

[release-branch.go1.11] cmd/compile: add necessary operand to mergePoint in rewrite rules

2019-07-08T17:48:29Z

A missing operand to mergePoint caused lower to place values in the wrong blocks. Includes test, belt+suspenders to do both ssa check and verify the output (was is how the bug was originally observed). The fixed bug here is very likely present in Go versions 1.9-1.12 on amd64 and s390x Updates #32680. Fixes #32711. Change-Id: I63e702c4c40602cb795ef71b1691eb704d38ccc7 Reviewed-on: https://go-review.googlesource.com/c/go/+/183059 Run-TryBot: David Chase TryBot-Result: Gobot Gobot Reviewed-by: Cherry Zhang (cherry picked from commit 769fda2d5110eef6146d7df3bf0219872c9b0da6) Reviewed-on: https://go-review.googlesource.com/c/go/+/183242

[release-branch.go1.11] cmd/link: revise previous __DWARF segment protection fix

2019-07-08T17:04:05Z

Tweak the previous fix for issue 32673 (in CL 182958) to work around problems with c-shared build mode that crop up on some of the builders (10.11, 10.12). We now consistently set vmaddr and vmsize to zero for the DWARF segment regardless of build mode. Fixes #32696. Change-Id: Id1fc213590ad00c28352925e2d754d760e022b5e Reviewed-on: https://go-review.googlesource.com/c/go/+/183237 Reviewed-by: Cherry Zhang Reviewed-by: David Chase Reviewed-on: https://go-review.googlesource.com/c/go/+/183400 Run-TryBot: Cherry Zhang TryBot-Result: Gobot Gobot

[release-branch.go1.11] cmd/link: macos: set initial protection of 0 for __DWARF segment

2019-07-08T17:03:39Z

For later versions of MacOS, the dynamic loader is more picky about enforcing restrictions on __DWARF MachO load commands/segments, triggering aborts of the form dyld: malformed mach-o image: segment __DWARF has vmsize < filesize for Go programs that use cgo on Darwin. The error is being triggered because the Go linker is setting "vmsize" in the DWARF segment entry to zero as a way to signal that the DWARF doesn't need to be mapped into memory at runtime (which we need to continue to do). This patch changes the initial protection on the __DWARF segment to zero, which dyld seems to be happy with (this is used for other similar non-loadable sections such as __LLVM). Updates #32696 Change-Id: I9a73449c6d26c172f3d70361719943af381f37e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/182958 Run-TryBot: Than McIntosh TryBot-Result: Gobot Gobot Reviewed-by: Cherry Zhang Reviewed-on: https://go-review.googlesource.com/c/go/+/183399

[release-branch.go1.11] cmd/compile: fix range analysis of small signed integers

2019-07-01T17:22:40Z

For int8, int16, and int32, comparing their unsigned value to MaxInt64 to determine non-negativity doesn't make sense, because they have negative values whose unsigned representation is smaller than that. Fix is simply to compare with the appropriate upper bound based on the value type's size. Fixes #32582. Change-Id: Ie7afad7a56af92bd890ba5ff33c86d1df06cfd9a Reviewed-on: https://go-review.googlesource.com/c/go/+/181797 Run-TryBot: Matthew Dempsky Reviewed-by: Josh Bleecher Snyder Reviewed-by: David Chase Reviewed-by: Keith Randall TryBot-Result: Gobot Gobot (cherry picked from commit f44404ebbfeff57f3e45ebf4b314a320bb89841f) Reviewed-on: https://go-review.googlesource.com/c/go/+/181979 Reviewed-by: Russ Cox