| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I336b7203a30b17c738f1711dc4dc7654a3d17ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/370556
Trust: Alex Rakoczy <alex@golang.org>
Run-TryBot: Alex Rakoczy <alex@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Pull in security fix
a5309b3 http2: cap the size of the server's canonical header cache
Updates #50058
Fixes CVE-2021-44716
Change-Id: Ifdd13f97fce168de5fb4b2e74ef2060d059800b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/370575
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Generally speaking Go functions make no guarantees
about what has happened to result parameters on error,
and Pipe is no exception: callers should avoid looking at
p if Pipe returns an error.
However, we had a bug in which ForkExec was using the
content of p after a failed Pipe, and others may too.
As a robustness fix, make Pipe avoid writing to p on failure.
Updates #50057
Change-Id: Ie8955025dbd20702fabadc9bbe1d1a5ac0f36305
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291271
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370515
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
Pipe (and therefore forkLockPipe) does not make any guarantees
about the state of p after a failed Pipe(p). Avoid that assumption
and the too-clever goto, so that we don't accidentally Close a real fd
if the failed pipe leaves p[0] or p[1] set >= 0.
Updates #50057
Fixes CVE-2021-44717
Change-Id: Iff8e19a6efbba0c73cc8b13ecfae381c87600bb4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291270
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370514
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Rakoczy <alex@golang.org>
|
|
This reverts commit 98ef91b38e38289b8de07a77cad7a0c4208f0106.
Reason for revert: Reducing risk for upcoming minor release.
Change-Id: Ic18609383384ebbb49d144bcb17131077de390c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/370554
Run-TryBot: Alex Rakoczy <alex@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Fixes #49923.
Change-Id: I74dd9170a51cc93ce3ec5e5860c2eb2912f081f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312729
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit b6ff3c69d5fdf933f5265f95ae4bb12eaecc792f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368835
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
|
|
Change-Id: I2a6eb84b309b0793b5dd339a435764fb2d9c1fb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/368694
Trust: Heschi Kreinick <heschi@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
struct/array
This is backport of CL 3651594, with the test from CL 360057.
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes #49391
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/361597
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Pull in approved backports to golang.org/x/net/http2:
64539c1 http2: don't count aborted streams as active in tests
e677a40 ipv6: OpenBSD does not appear to support multicast loopback
d8ae719 net/http2: Fix handling of expect continue
cc2f99c http2: avoid busy loop when ResponseHeaderTimeout is set
5533dda http2: avoid spurious RoundTrip error when server closes and resets stream
26ec667 http2: close conns after use when req.Close is set
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.16-vendor
go: downloading golang.org/x/net v0.0.0-20211201233224-64539c132272
go get: upgraded golang.org/x/net v0.0.0-20211101194150-d8c3cde3c676 => v0.0.0-20211201233224-64539c132272
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Fixes #49904.
Fixes #49623.
Fixes #49661.
Fixes #49560.
Fixes #49908.
Fixes #49910.
Change-Id: I73261b189f84cf1919a79129ec36a1c187723133
Reviewed-on: https://go-review.googlesource.com/c/go/+/368594
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Ensure that user ConnState callbacks have completed before returning
from (*httptest.Server).Close.
Fixes: #49851
Updates: #37510
Updates: #37505
Updates: #45237
Change-Id: I8fe7baa089fbe4f3836bf6ae9767c7b1270d1331
Reviewed-on: https://go-review.googlesource.com/c/go/+/304829
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 5cec8b85e5dc75ef21b62efb6bd93f9007385e34)
Reviewed-on: https://go-review.googlesource.com/c/go/+/367516
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
responses
Server handlers may set a "Transfer-Encoding: identity" header on
responses to disable chunking, but this header should not be sent
on the wire.
For #49194.
Fixes #49567.
Change-Id: I46a9e3b8ff9d93edd7d1c34d264fc309fa322ad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/359176
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit b69b2f63d65609b400b4a40ae01e4a48638f050f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368086
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
body read
When sending a Request with a non-context deadline, we create a
context with a timeout. This context is canceled when closing the
response body, and also if a read from the response body returns
an error (including io.EOF).
Cancelling the context in Response.Body.Read interferes with the
HTTP/2 client cleaning up after a request is completed, and is
unnecessary: The user should always close the body, the impact
from not canceling the context is minor (the context timer leaks
until it fires).
For #49366.
Fixes #49558.
Change-Id: Ieaed866116916261d9079f71d8fea7a7b303b8fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/361919
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 76fbd6167364fb98e3ebe946cfc16b5b84d4240e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/368084
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
to prevent GC
When syscall's DLL.FindProc calls into syscall_getprocaddress with a
byte slice pointer, we need to keep those bytes alive. Otherwise the GC
will collect the allocation, and we wind up calling `GetProcAddress` on
garbage, which showed up as various flakes in the builders. It turns out
that this problem extends to many uses of //go:cgo_unsafe_args
throughout, on all platforms. So this patch fixes the issue by keeping
non-integer pointer arguments alive through their invocation in
//go:cgo_unsafe_args functions.
Fixes #49867.
Updates #49731.
Change-Id: I93e4fbc2e8e210cb3fc53149708758bb33f2f9c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/368356
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
to a zone transition
The old implement passed start - 1 or end in func lookup to adjust the offset.But if the time is close to the last zoneTrans, like the issue, testcase and comment, the "start" from lookup will be omega. It can't be adjusted correctly.
Fixes #49406
Change-Id: Ibaf82dc4db6d5dd3279796f003d2b19c38a26341
Reviewed-on: https://go-review.googlesource.com/c/go/+/360616
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Findley <rfindley@google.com>
(cherry picked from commit 90462dfc3aa99649de90bb587af56a9cb0214665)
Reviewed-on: https://go-review.googlesource.com/c/go/+/361954
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
script tests
For #49138
Updates #49723
Fixes #49728
Change-Id: Ia93130fdc042a1e2107be95cccd7e7eeaa909a87
Reviewed-on: https://go-review.googlesource.com/c/go/+/366254
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 189b4a2f428be7264db76e5275c96d98b847383b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/366258
TryBot-Result: Go Bot <gobot@golang.org>
|
|
https://github.com/googleapis/google-cloud-go has changed the default
branch from master to main, causing mod_get_direct failed on longtest.
Change-Id: I8fe0356b2ff532d1fdedbcb1e1832d7335babaa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361965
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit b7529c3617a64ed5d1e2a6c7a9366d4a4988a38d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/362536
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: I872971806a723e6add42bb78f91a8ef8586f3d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/361199
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Previously, opening a zip with (*Reader).Open could result in a panic if
the zip contained a file whose name was exclusively made up of slash
characters or ".." path elements.
Open could also panic if passed the empty string directly as an argument.
Now, any files in the zip whose name could not be made valid for
fs.FS.Open will be skipped, and no longer added to the fs.FS file list,
although they are still accessible through (*Reader).File.
Note that it was already the case that a file could be accessible from
(*Reader).Open with a name different from the one in (*Reader).File, as
the former is the cleaned name, while the latter is the original one.
Finally, made the actual panic site robust as a defense-in-depth measure.
Fixes CVE-2021-41772
Fixes #48251
Updates #48085
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I6271a3f2892e7746f52e213b8eba9a1bba974678
Reviewed-on: https://go-review.googlesource.com/c/go/+/349770
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Julie Qiu <julie@golang.org>
(cherry picked from commit b24687394b55a93449e2be4e6892ead58ea9a10f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/360858
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Pull in approved backports to golang.org/x/net/http2:
d8c3cde set ContentLength to -1 for HEAD response with no Content-Length
7b24c0a set Response.ContentLength to 0 when headers end stream
c4031f5 don't abort half-closed streams on server connection close
2f744fa on write errors, close ClientConn before returning from RoundTrip
275be3f deflake TestTransportReqBodyAfterResponse_200
d26011a close the Request's Body when aborting a stream
e5dd05d return unexpected eof on empty response with non-zero content length
640e170 don't rely on system TCP buffer sizes in TestServer_MaxQueuedControlFrames
198b78c detect write-blocked PING frames
20ed279 avoid race in TestTransportReqBodyAfterResponse_403.
d585ef0 avoid clientConnPool panic when NewClientConn fails
d06dfc7 avoid extra GetConn trace call
1760f31 refactor request write flow
6e87631 remove PingTimeout from TestTransportPingWhenReading
b843c7d fix Transport connection pool TOCTOU max concurrent stream bug
ab1d67c shut down idle Transport connections after protocol errors
3741e47 remove check for read-after-close of request bodies
2df4c53 fix race in DATA frame padding refund
d7eefc9 avoid blocking while holding ClientConn.mu
78e8d65 fix off-by-one error in client check for max concurrent streams
828651b close request body after early RoundTrip failures
59c0c25 limit client initial MAX_CONCURRENT_STREAMS
524fcad make Transport not reuse conns after a stream protocol error
0fe5f8a accept zero-length block fragments in HEADERS frames
0e5043f close the request body if needed
bb4ce86 reduce frameScratchBuffer caching aggressiveness
3112343 also set "http/1.1" ALPN in ConfigureServer
63939f4 switch to ASCII equivalents of string functions
54161af use (*tls.Dialer).DialContext in dialTLS
75b906f discard DATA frames with higher stream IDs during graceful shutdown
1dfe517 rework Ping test to rely less on timing
By doing:
$ go get -d golang.org/x/net@internal-branch.go1.16-vendor
go get: upgraded golang.org/x/net v0.0.0-20210901185431-d2e9a4ea682f => v0.0.0-20211101194150-d8c3cde3c676
$ go mod tidy
$ go mod vendor
$ go generate -run=bundle std
Fixes #49076.
Fixes #48822.
Fixes #48649.
Change-Id: Ie17f327eef2b6e6a9a1ac7635c5c4daef792e893
Reviewed-on: https://go-review.googlesource.com/c/go/+/359774
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
command
Fail out when loading a file that contains a dynamic symbol table
command that indicates a larger number of symbols than exist in the
loaded symbol table.
Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for
reporting this issue.
Updates #48990
Fixes #48991
Fixes CVE-2021-41771
Change-Id: Ic3d6e6529241afcc959544b326b21b663262bad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/355990
Reviewed-by: Julie Qiu <julie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
(cherry picked from commit 61536ec03063b4951163bd09609c86d82631fa27)
Reviewed-on: https://go-review.googlesource.com/c/go/+/359454
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
wasm
On wasm, the wasm_exec.js helper passes the command line arguments and
environment variables via a reserved space in the wasm linear memory.
Increase this reserved space from 4096 to 8192 bytes so more environment
variables can fit into the limit.
Later, after https://golang.org/cl/350737 landed, we can switch to the
WASI interface for getting the arguments and environment. This would
remove the limit entirely.
Updates #49011.
Fixes #49153.
Change-Id: I48a6e952a97d33404ed692c98e9b49c5cd6b269b
Reviewed-on: https://go-review.googlesource.com/c/go/+/358194
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 252324e879e32f948d885f787decf8af06f82be9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/359400
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
|
|
atomics
Both netpollblock and netpollunblock read gpp using a non-atomic load.
When consuming a ready event, netpollblock clears gpp using a non-atomic
store, thus skipping a barrier.
Thus on systems with weak memory ordering, a sequence like so this is
possible:
T1 T2
1. netpollblock: read gpp -> pdReady
2. netpollblock: store gpp -> 0
3. netpollunblock: read gpp -> pdReady
4. netpollunblock: return
i.e., without a happens-before edge between (2) and (3), netpollunblock
may read the stale value of gpp.
Switch these access to use atomic loads and stores in order to create
these edges.
For ease of future maintainance, I've simply changed rg and wg to always
be accessed atomically, though I don't believe pollOpen or pollClose
require atomics today.
For #48925
Fixes #49009
Change-Id: I903ea667eea320277610b4f969129935731520c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/355952
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 1b072b3ed56c18619587354f499fcda5279718a2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/356370
|
|
range for arm
Ensure constant shift amounts are in the range [0-31]. When shift amounts
are out of range, bad things happen. Shift amounts out of range occur
when lowering 64-bit shifts (we take an in-range shift s in [0-63] and
calculate s-32 and 32-s, both of which might be out of [0-31]).
The constant shift operations themselves still work, but their shift
amounts get copied unmolested to operations like ORshiftLL which use only
the low 5 bits. That changes an operation like <<100 which unconditionally
produces 0, to <<4, which doesn't.
Fixes #48478
Change-Id: I87363ef2b4ceaf3b2e316426064626efdfbb8ee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/350969
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit eff27e858b771bf5e0b5e7e836827c7d2941e6d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/351070
Reviewed-by: Austin Clements <austin@google.com>
|
|
Fixes #48474
Change-Id: Ic1e918f916eae223a3b530a51a58f03031924670
Reviewed-on: https://go-review.googlesource.com/c/go/+/350913
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/351072
Reviewed-by: Austin Clements <austin@google.com>
|
|
Change-Id: I7328dd94a85b97ec8c3ecf4f56eca9c56a6d806e
Reviewed-on: https://go-review.googlesource.com/c/go/+/354593
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
overwrite global data
On Wasm, wasm_exec.js puts command line arguments at the beginning
of the linear memory (following the "zero page"). Currently there
is no limit for this, and a very long command line can overwrite
the program's data section. Prevent this by limiting the command
line to 4096 bytes, and in the linker ensuring the data section
starts at a high enough address (8192).
(Arguably our address assignment on Wasm is a bit confusing. This
is the minimum fix I can come up with.)
Thanks to Ben Lubar for reporting this issue.
Change by Cherry Mui <cherryyz@google.com>.
For #48797
Fixes #48799
Fixes CVE-2021-38297
Change-Id: I0f50fbb2a5b6d0d047e3c134a88988d9133e4ab3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1205933
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/354591
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
|
|
For #39807
For #48436
Fixes #48443
Change-Id: I75f82fd8738dd2f11f0c69b1230e1be1abc36024
Reviewed-on: https://go-review.googlesource.com/c/go/+/350730
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
(cherry picked from commit ba1c52d7d77724de4407572bd02421c36df3d78a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/351116
|
|
When the adjustTimers function removed a timer it assumed it was
sufficient to continue the heap traversal at that position.
However, in some cases a timer will be moved to an earlier
position in the heap. If that timer is timerModifiedEarlier,
that can leave timerModifiedEarliest not correctly representing
the earlier such timer.
Fix the problem by restarting the heap traversal at the earliest
changed position.
For #47762
Fixes #47858
Change-Id: I152bbe62793ee40a680baf49967bcb89b1f94764
Reviewed-on: https://go-review.googlesource.com/c/go/+/343882
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 2da3375e9b4980e368a8641f54cc53c4af4d1a12)
Reviewed-on: https://go-review.googlesource.com/c/go/+/350000
|
|
Change-Id: I1926e1506e56fd0484bec71f7b43cee62e41b5b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/348812
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
|
|
data race
This adds a new lock protecting "tmpl".
This is a copy of https://golang.org/cl/257817 by Andreas Fleig,
updated for current tip, and updated to start running the
html/template TestEscapeRace test.
Thanks to @bep for providing the test case.
For #39807
Fixes #47042
Change-Id: Ic8874484290283a49116812eeaffb8608346dc70
Reviewed-on: https://go-review.googlesource.com/c/go/+/316669
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 496d7c691481966fd6ea806205aa025698a172af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/348580
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
For #47691.
Change-Id: I6650fdfc78786fc47a54167bf2f9061422bbb343
Reviewed-on: https://go-review.googlesource.com/c/go/+/347031
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
overflowing
If the indicated directory size in the archive header is so large that
subtracting it from the archive size overflows a uint64, the check that
the indicated number of files in the archive can be effectively
bypassed. Prevent this from happening by checking that the indicated
directory size is less than the size of the archive.
Thanks to the OSS-Fuzz project for discovering this issue and to
Emmanuel Odeke for reporting it.
Fixes #47985
Updates #47801
Fixes CVE-2021-39293
Change-Id: Ifade26b98a40f3b37398ca86bd5252d12394dd24
Reviewed-on: https://go-review.googlesource.com/c/go/+/343434
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit bacbc33439b124ffd7392c91a5f5d96eca8c0c0b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/345409
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Cherry Mui <cherryyz@google.com>
|
|
On Linux ARMv6 and below runtime/internal/atomic.Cas calls into a kernel
cas helper at a fixed address. If a SIGPROF arrives while executing the
kernel helper, the sigprof lostAtomic logic will miss that we are
potentially in the spinlock critical section, which could cause
a deadlock when using atomics later in sigprof.
For #47505
Fixes #47675
Change-Id: If8ba0d0fc47e45d4e6c68eca98fac4c6ed4e43c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/341889
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 20a620fd9f7bc35739c1af3602d53808d0430814)
Reviewed-on: https://go-review.googlesource.com/c/go/+/341853
|
|
test
Change the TestInstallationImporter testpoint to query type
information for sort.Search instead of sort.Ints. The latter function
changed recently (1.16 timeframe), parameter "a" is now "x". A better
candidate for this sort of query is sort.Search, which has been stable
for a while.
Fixes #47610.
Change-Id: I314476eac0b0802f86f5cbce32195cab2926db83
Reviewed-on: https://go-review.googlesource.com/c/go/+/294290
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 0f66fb7b856b02497cf801ce72d80f375f53358b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/340952
|
|
Change-Id: I5a8616596c53b43f60487e19385b6a60af1addfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/339451
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Damien Neil <dneil@google.com>
Trust: Carlos Amedee <carlos@golang.org>
|
|
TestCancelRequestWhenSharingConnection
This test made many requests over the same connection for 10
seconds, trusting that this will exercise the request cancelation
race from #41600.
Change the test to exhibit the specific race in a targeted fashion
with only two requests.
Fixes #47535.
Updates #41600.
Updates #47016.
Change-Id: If99c9b9331ff645f6bb67fe9fb79b8aab8784710
Reviewed-on: https://go-review.googlesource.com/c/go/+/339594
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
(cherry picked from commit 6e738868a7a943d7d4fd6bb1963e7f6d78111726)
Reviewed-on: https://go-review.googlesource.com/c/go/+/339830
|
|
This patch reinstates a fix for PowerPC with regard to making VDSO calls
while receiving a signal, and subsequently crashing. The crash happens
because certain VDSO calls can modify the r30 register, which is where g
is stored. This change was reverted for PowerPC because r30 is supposed
to be a non-volatile register. This is true, but that only makes a
guarantee across function calls, but not "within" a function call. This
patch was seemingly fine before because the Linux kernel still had hand
rolled assembly VDSO function calls, however with a recent change to C
function calls it seems the compiler used can generate instructions
which temporarily clobber r30. This means that when we receive a signal
during one of these calls the value of r30 will not be the g as the
runtime expects, causing a segfault.
You can see from this assembly dump how the register is clobbered during
the call:
(the following is from a 5.13rc2 kernel)
```
Dump of assembler code for function __cvdso_clock_gettime_data:
0x00007ffff7ff0700 <+0>: cmplwi r4,15
0x00007ffff7ff0704 <+4>: bgt 0x7ffff7ff07f0 <__cvdso_clock_gettime_data+240>
0x00007ffff7ff0708 <+8>: li r9,1
0x00007ffff7ff070c <+12>: slw r9,r9,r4
0x00007ffff7ff0710 <+16>: andi. r10,r9,2179
0x00007ffff7ff0714 <+20>: beq 0x7ffff7ff0810 <__cvdso_clock_gettime_data+272>
0x00007ffff7ff0718 <+24>: rldicr r10,r4,4,59
0x00007ffff7ff071c <+28>: lis r9,32767
0x00007ffff7ff0720 <+32>: std r30,-16(r1)
0x00007ffff7ff0724 <+36>: std r31,-8(r1)
0x00007ffff7ff0728 <+40>: add r6,r3,r10
0x00007ffff7ff072c <+44>: ori r4,r9,65535
0x00007ffff7ff0730 <+48>: lwz r8,0(r3)
0x00007ffff7ff0734 <+52>: andi. r9,r8,1
0x00007ffff7ff0738 <+56>: bne 0x7ffff7ff07d0 <__cvdso_clock_gettime_data+208>
0x00007ffff7ff073c <+60>: lwsync
0x00007ffff7ff0740 <+64>: mftb r30 <---- RIGHT HERE
=> 0x00007ffff7ff0744 <+68>: ld r12,40(r6)
```
What I believe is happening is that the kernel changed the PowerPC VDSO
calls to use standard C calls instead of using hand rolled assembly. The
hand rolled assembly calls never touched r30, so this change was safe to
roll back. That does not seem to be the case anymore as on the 5.13rc2
kernel the compiler *is* generating assembly which modifies r30, making
this change again unsafe and causing a crash when the program receives a
signal during these calls (which will happen often due to async
preempt). This change happened here:
https://lwn.net/ml/linux-kernel/235e5571959cfa89ced081d7e838ed5ff38447d2.1601365870.git.christophe.leroy@csgroup.eu/.
I realize this was reverted due to unexplained hangs in PowerPC
builders, but I think we should reinstate this change and investigate
those issues separately:
https://github.com/golang/go/commit/f4ca3c1e0a2066ca4f7bd6203866d282ed34acf2
Fixes #46858
Change-Id: Ib18d7bbfc80a1a9cb558f0098878d41081324b52
GitHub-Last-Rev: c3002bcfca3ef58b27485e31328e6297b7a9dfe7
GitHub-Pull-Request: golang/go#46767
Reviewed-on: https://go-review.googlesource.com/c/go/+/328110
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
(cherry picked from commit 16e82be454cbf41299e6a055d54d489ca4612ee0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/334410
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
package paths in 'go mod vendor'
copyMetadata walk-up to parent directory until the pkg become modPath.
But pkg should be slash-separated paths. It have to use path.Dir instead of
filepath.Dir.
Updates #46867
Fixes #47015
Change-Id: I44cf1429fe52379a7415b94cc30ae3275cc430e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/330149
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 835d86a17ebf32a3cb081f66119c74363dbd8825)
Reviewed-on: https://go-review.googlesource.com/c/go/+/332329
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Updates #46528
Fixes #46551
Change-Id: I2453d321ece878ea7823865758aa4a16b3ed7fe8
Reviewed-on: https://go-review.googlesource.com/c/go/+/325430
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit e552a6d31270c86064632af1d092e0db5a930250)
Reviewed-on: https://go-review.googlesource.com/c/go/+/334371
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
non-standard calls on ARM64
On ARM64, (external) linker generated trampoline may clobber R16
and R17. In CL 183842 we change Duff's devices not to use those
registers. However, this is not enough. The register allocator
also needs to know that these registers may be clobbered in any
calls that don't follow the standard Go calling convention. This
include Duff's devices and the write barrier.
Fixes #46928.
Updates #32773.
Change-Id: Ia52a891d9bbb8515c927617dd53aee5af5bd9aa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/184437
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
(cherry picked from commit 11b4aee05bfe83513cf08f83091e5aef8b33e766)
Reviewed-on: https://go-review.googlesource.com/c/go/+/331029
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
In CL 326211 a change was made to switch "go.map.zero" symbols from
non-pkg DUPOK symbols to hashed symbols. The intent of this change was
ensure that in cases where there are multiple competing go.map.zero
symbols feeding into a link, the largest map.zero symbol is selected.
The change was buggy, however, and resulted in duplicate symbols in
the final binary (see bug cited below for details). This duplication
was relatively benign for linux/ELF, but causes duplicate definition
errors on Windows.
This patch switches "go.map.zero" symbols back from hashed symbols to
non-pkg DUPOK symbols, and updates the relevant code in the loader to
ensure that we do the right thing when there are multiple competing
DUPOK symbols with different sizes.
Fixes #47289.
Change-Id: I8aeb910c65827f5380144d07646006ba553c9251
Reviewed-on: https://go-review.googlesource.com/c/go/+/334930
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 49402bee36fd3d5cee9f4b2d2e1e8560ead0203b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/335629
|
|
in a cycle
When hitting an import cycle in reusePackage, and there is already
an error set, make sure IsImportCycle is set so that we don't
end up stuck in a loop.
Updates #25830
Fixes #47348
Change-Id: Iba966aea4a637dfc34ee22782a477209ac48c9bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/301289
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit cdd08e615a9b92742b21a94443720b6d70452510)
Reviewed-on: https://go-review.googlesource.com/c/go/+/336649
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
|
|
request body
Reading from an incoming request body after the request handler aborts
with a panic can cause a panic, becuse http.Server does not (contrary
to its documentation) close the request body in this case.
Always close the incoming request body in ReverseProxy.ServeHTTP to
ensure that any in-flight outgoing requests using the body do not
read from it.
Fixes #47474
Updates #46866
Fixes CVE-2021-36221
Change-Id: I310df269200ad8732c5d9f1a2b00de68725831df
Reviewed-on: https://go-review.googlesource.com/c/go/+/333191
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit b7a85e0003cedb1b48a1fd3ae5b746ec6330102e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/338551
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
In CL 336432 we changed adjusttimers so that it no longer cleared
timerModifiedEarliest if there were no timersModifiedEarlier timers.
This caused some Google internal tests to time out, presumably due
to the increased contention on timersLock. We can avoid that by
simply not skipping the loop in adjusttimers, which lets us safely
clear timerModifiedEarliest. And if we don't skip the loop, then there
isn't much reason to keep the count of timerModifiedEarlier timers at all.
So remove it.
The effect will be that for programs that create some timerModifiedEarlier
timers and then remove them all, the program will do an occasional
additional loop over all the timers. And, programs that have some
timerModifiedEarlier timers will always loop over all the timers,
without the quicker exit when they have all been seen. But the loops
should not occur all that often, due to timerModifiedEarliest.
For #47329
For #47332
Change-Id: I7b244c1244d97b169a3c7fbc8f8a8b115731ddee
Reviewed-on: https://go-review.googlesource.com/c/go/+/337309
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit bfbb288574841f2db2499a580d7bf985a5df4556)
Reviewed-on: https://go-review.googlesource.com/c/go/+/338649
|
|
adjustTimers is 0
This avoids a race when a new timerModifiedEarlier timer is created by
a different goroutine.
For #47329
Fixes #47332
Change-Id: I6f6c87b4a9b5491b201c725c10bc98e23e0ed9d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/336432
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 798ec73519a7226d6d436e42498a54aed23b8468)
Reviewed-on: https://go-review.googlesource.com/c/go/+/336689
|
|
Change-Id: Ic394096a2d9cc5927b812f3c457282b26901b2b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/334089
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
When casting the certificate public key in generateClientKeyExchange,
check the type is appropriate. This prevents a panic when a server
agrees to a RSA based key exchange, but then sends an ECDSA (or
other) certificate.
Updates #47143
Fixes #47145
Fixes CVE-2021-34558
Thanks to Imre Rad for reporting this issue.
Change-Id: Iabccacca6052769a605cccefa1216a9f7b7f6aea
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1116723
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/334029
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
of hard failing
Instead of hard failing on a single bad record, filter the bad records
and return anything valid. This only applies to the methods which can
return multiple records, LookupMX, LookupNS, LookupSRV, and LookupAddr.
When bad results are filtered out, also return an error, indicating
that this filtering has happened.
Updates #46241
Updates #46979
Fixes #46999
Change-Id: I6493e0002beaf89f5a9795333a93605abd30d171
Reviewed-on: https://go-review.googlesource.com/c/go/+/332549
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 296ddf2a936a30866303a64d49bc0e3e034730a8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/333330
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Bypass hostname validity checking when a null mx record is returned as,
defined in RFC 7505.
Updates #46979
Updates #46999
Change-Id: Ibe683bd6b47333a8ff30909fb2680ec8e10696ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/332094
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
(cherry picked from commit 03761ede028d811dd7d7cf8a2690d4bfa2771d85)
Reviewed-on: https://go-review.googlesource.com/c/go/+/332371
Run-TryBot: Katie Hockman <katie@golang.org>
|
|
CL 249238 changes ResponseWriter.ReadFrom to probe the source with
a single read of sniffLen bytes before writing the response header.
If the source returns less than sniffLen bytes without reaching
EOF, this can cause Content-Type and Content-Length detection to
fail.
Fix ResponseWrite.ReadFrom to copy a full sniffLen bytes from
the source as a probe.
Drop the explicit call to w.WriteHeader; writing the probe will
trigger a WriteHeader call.
Consistently use io.CopyBuffer; ReadFrom has already acquired a
copy buffer, so it may as well use it.
Fixes #44984.
Updates #44953.
Change-Id: Ic49305fb827a2bd7da4764b68d64b797b5157dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/301449
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 831f9376d8d730b16fb33dfd775618dffe13ce7a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/324971
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
