commit e71b61180aa19a60c23b3b7e3f6586726ebe4fd1 [browse]
Author: Alexander Rakoczy
Date: 2020-08-06 10:05:40 -04:00

[release-branch.go1.13-security] go1.13.15

Change-Id: I4922f24774168f1c991b486276257a1ed18d34b6
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/814547
Reviewed-by: Katie Hockman <katiehockman@google.com>

commit ec5b63a6a2b6205cc204e9ce856e7517a1b989d2 [browse]
Author: Katie Hockman
Date: 2020-08-04 11:45:32 -04:00

[release-branch.go1.13-security] encoding/binary: read at most MaxVarintLen64 bytes in ReadUvarint

This CL ensures that ReadUvarint consumes only a limited
amount of input (instead of an unbounded amount).

On some inputs, ReadUvarint could read an arbitrary number
of bytes before deciding to return an overflow error.
After this CL, ReadUvarint returns that same overflow
error sooner, after reading at most MaxVarintLen64 bytes.

Fix authored by Robert Griesemer and Filippo Valsorda.

Thanks to Diederik Loerakker, Jonny Rhea, Raúl Kripalani,
and Preston Van Loon for reporting this.

Fixes CVE-2020-16845

Change-Id: Ie0cb15972f14c38b7cf7af84c45c4ce54909bb8f
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/812099
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/812324

commit d3ba94164a1c404a01369fb54ddd4f5b94d91348 [browse]
Author: Andrew Bonventre
Date: 2020-07-16 17:41:24 -04:00

[release-branch.go1.13] go1.13.14

Change-Id: Id54fd93e1839c28e40e9fcdaa5e7304dae274565
Reviewed-on: https://go-review.googlesource.com/c/go/+/243139
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

commit 42e7927c5fe2da4d00786a9025bc7f8f994b0fa4 [browse]
Author: Emmanuel T Odeke
Date: 2020-07-14 18:20:47 -07:00

[release-branch.go1.13] database/sql: backport 5 Tx rollback related CLs

Manually backported the subject CLs, because of lack of
Gerrit "forge-author" permissions, but also because the prior
cherry picks didn't apply cleanly, due to a tight relation chain.

The backport comprises of:
* CL 174122
* CL 216197
* CL 223963
* CL 216240
* CL 216241

Note:
Due to the restrictions that we cannot retroactively
introduce API changes to Go1.13.13 that weren't in Go1.13, the Conn.Validator
interface (from CL 174122, CL 223963) isn't exposed, and drivers will just be
inspected, for if they have an IsValid() bool method implemented.

For a description of the content of each CL:

* CL 174122:
database/sql: process all Session Resets synchronously

Adds a new interface, driver.ConnectionValidator, to allow
drivers to signal they should not be used again,
separatly from the session resetter interface.
This is done now that the session reset is done
after the connection is put into the connection pool.

Previous behavior attempted to run Session Resets
in a background worker. This implementation had two
problems: untested performance gains for additional
complexity, and failures when the pool size
exceeded the connection reset channel buffer size.

* CL 216197:
database/sql: check conn expiry when returning to pool, not when handing it out

With the original connection reuse strategy, it was possible that
when a new connection was requested, the pool would wait for an
an existing connection to return for re-use in a full connection
pool, and then it would check if the returned connection was expired.
If the returned connection expired while awaiting re-use, it would
return an error to the location requestiong the new connection.
The existing call sites requesting a new connection was often the last
attempt at returning a connection for a query. This would then
result in a failed query.

This change ensures that we perform the expiry check right
before a connection is inserted back in to the connection pool
for while requesting a new connection. If requesting a new connection
it will no longer fail due to the connection expiring.

* CL 216240:
database/sql: prevent Tx statement from committing after rollback

It was possible for a Tx that was aborted for rollback
asynchronously to execute a query after the rollback had completed
on the database, which often would auto commit the query outside
of the transaction.

By W-locking the tx.closemu prior to issuing the rollback
connection it ensures any Tx query either fails or finishes
on the Tx, and never after the Tx has rolled back.

* CL 216241:
database/sql: on Tx rollback, retain connection if driver can reset session

Previously the Tx would drop the connection after rolling back from
a context cancel. Now if the driver can reset the session,
keep the connection.

* CL 223963
database/sql: add test for Conn.Validator interface

This addresses comments made by Russ after
https://golang.org/cl/174122 was merged. It addes a test
for the connection validator and renames the interface to just
"Validator".

Updates #31480
Updates #32530
Updates #32942
Updates #34775
Fixes #40205

Change-Id: I6d7307180b0db0bf159130d91161764cf0f18b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/242522
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>

commit 6e1b89a431337a1e4584bd15f3a1af9c5c7b1bb0 [browse]
Author: Katie Hockman
Date: 2020-07-14 14:39:38 -04:00

[release-branch.go1.13] all: merge release-branch.go1.13-security into release-branch.go1.13

Change-Id: Id0cca0e1006d92960e7f665d41111483c0fcea13