net/url does not currently limit the number of query parameters parsed by
url.ParseQuery or URL.Query.
When parsing a application/x-www-form-urlencoded form,
net/http.Request.ParseForm will parse up to 10 MB of query parameters.
An input consisting of a large number of small, unique parameters can
cause excessive memory consumption.
We now limit the number of query parameters parsed to 10000 by default.
The limit can be adjusted by setting GODEBUG=urlmaxqueryparams=<n>.
Setting urlmaxqueryparams to 0 disables the limit.
Thanks to jub0bs for reporting this issue.
Fixes#77101
Fixes CVE-2025-61726
Change-Id: Iee3374c7ee2d8586dbf158536d3ade424203ff66
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3020
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/736712
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
First, we centralize all random bytes generation through drbg.Read. The
rest of the FIPS 140-3 module can't use external functions anyway, so
drbg.Read needs to have all the logic.
Then, make sure that the crypto/... tree uses drbg.Read (or the new
crypto/internal/rand.Reader wrapper) instead of crypto/rand, so it is
unaffected by applications setting crypto/rand.Reader.
Next, pass all unspecified random io.Reader parameters through the new
crypto/internal/rand.CustomReader, which just redirects to drbg.Read
unless GODEBUG=cryptocustomrand=1 is set. Move all the calls to
MaybeReadByte there, since it's only needed for these custom Readers.
Finally, add testing/cryptotest.SetGlobalRandom which sets
crypto/rand.Reader to a locked deterministic source and overrides
drbg.Read. This way SetGlobalRandom should affect all cryptographic
randomness in the standard library.
Fixes#70942
Co-authored-by: qiulaidongfeng <2645477756@qq.com>
Change-Id: I6a6a69641311d9fac318abcc6d79677f0e406100
Reviewed-on: https://go-review.googlesource.com/c/go/+/724480
Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Copy LabelSet to an internal package as label.Set, and include (escaped)
labels within goroutine stack dumps.
Labels are added to the goroutine header as quoted key:value pairs, so
the line may get long if there are a lot of labels.
To handle escaping, we add a printescaped function to the
runtime and hook it up to the print function in the compiler with a new
runtime.quoted type that's a sibling to runtime.hex. (in fact, we
leverage some of the machinery from printhex to generate escape
sequences).
The escaping can be improved for printable runes outside basic ASCII
(particularly for languages using non-latin stripts). Additionally,
invalid UTF-8 can be improved.
So we can experiment with the output format make this opt-in via a
a new tracebacklabels GODEBUG var.
Updates #23458
Updates #76349
Change-Id: I08e78a40c55839a809236fff593ef2090c13c036
Reviewed-on: https://go-review.googlesource.com/c/go/+/694119
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
When handling HTTP headers, net/http does not currently limit the number
of cookies that can be parsed. The only limitation that exists is for
the size of the entire HTTP header, which is controlled by
MaxHeaderBytes (defaults to 1 MB).
Unfortunately, this allows a malicious actor to send HTTP headers which
contain a massive amount of small cookies, such that as much cookies as
possible can be fitted within the MaxHeaderBytes limitation. Internally,
this causes us to allocate a massive number of Cookie struct.
For example, a 1 MB HTTP header with cookies that repeats "a=;" will
cause an allocation of ~66 MB in the heap. This can serve as a way for
malicious actors to induce memory exhaustion.
To fix this, we will now limit the number of cookies we are willing to
parse to 3000 by default. This behavior can be changed by setting a new
GODEBUG option: GODEBUG=httpcookiemaxnum. httpcookiemaxnum can be set to
allow a higher or lower cookie limit. Setting it to 0 will also allow an
infinite number of cookies to be parsed.
Thanks to jub0bs for reporting this issue.
For #75672
Fixes CVE-2025-58186
Change-Id: Ied58b3bc8acf5d11c880f881f36ecbf1d5d52622
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2720
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709855
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Removes the somewhat redundant vcs.FromDir, "allowNesting" argument,
which was always enabled, and disallow multiple VCS metadata folders
being present in a single directory. This makes VCS injection attacks
much more difficult.
Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue.
Fixes#74380
Fixes CVE-2025-4674
Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789
Reviewed-on: https://go-review.googlesource.com/c/go/+/686515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Commit-Queue: Carlos Amedee <carlos@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This implements RFC 9155 by removing support for SHA-1 algorithms:
- we don't advertise them in ClientHello and CertificateRequest
(where supportedSignatureAlgorithms is used directly)
- we don't select them in our ServerKeyExchange and CertificateVerify
(where supportedSignatureAlgorithms filters signatureSchemesForCertificate)
- we reject them in the peer's ServerKeyExchange and CertificateVerify
(where we check against the algorithms we advertised in ClientHello
and CertificateRequest)
Fixes#72883
Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818
Reviewed-on: https://go-review.googlesource.com/c/go/+/658216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
This CL adds two related features enabled by default via compatibility
GODEBUGs containermaxprocs and updatemaxprocs.
On Linux, containermaxprocs makes the Go runtime consider cgroup CPU
bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup
limit is lower than the number of logical CPUs available, then the
cgroup limit takes precedence.
On all OSes, updatemaxprocs makes the Go runtime periodically
recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has
changed. If GOMAXPROCS is set manually, this update does not occur. This
is intended primarily to detect changes to cgroup limits, but it applies
on all OSes because the CPU affinity mask can change as well.
The runtime only considers the limit in the leaf cgroup (the one that
actually contains the process), caching the CPU limit file
descriptor(s), which are periodically reread for updates. This is a
small departure from the original proposed design. It will not consider
limits of parent cgroups (which may be lower than the leaf), and it will
not detection cgroup migration after process start.
We can consider changing this in the future, but the simpler approach is
less invasive; less risk to packages that have some awareness of runtime
internals. e.g., if the runtime periodically opens new files during
execution, file descriptor leak detection is difficult to implement in a
stable way.
For #73193.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98
Reviewed-on: https://go-review.googlesource.com/c/go/+/670497
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
We previously disallowed all non-regular files being embedded. This CL
relaxes the restriction a little: if the GODEBUG embedfollowsymlinks=1
is set, we allow the leaf files being embedded (not the directories
containing them) to be symlinks. The files pointed to by the symlinks
must still be regular files.
This will be used when a Bazel build action executing the Go command is
running in a symlink-based sandbox. It's not something we want to enable
in general for now, so it's behind a GODEBUG.
Fixes#59924
Change-Id: I895be14c12de55b7d1b663d81bdda1df37d54804
Reviewed-on: https://go-review.googlesource.com/c/go/+/643215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This adds a new godebug to control whether the runtime applies the
anonymous memory mapping annotations added in https://go.dev/cl/646095.
It is enabled by default.
This has several effects:
* The feature is only enabled by default when the main go.mod has go >=
1.25.
* This feature can be disabled with GODEBUG=decoratemappings=0, or the
equivalents in go.mod or package main. See https://go.dev/doc/godebug.
* As an opaque setting, this option will not appear in runtime/metrics.
* This setting is non-atomic, so it cannot be changed after startup.
I am not 100% sure about my decision for the last two points.
I've made this an opaque setting because it affects every memory mapping
the runtime performs. Thus every mapping would report "non-default
behavior", which doesn't seem useful.
This setting could trivially be atomic and allow changes at run time,
but those changes would only affect future mappings. That seems
confusing and not helpful. On the other hand, going back to annotate or
unannotate every previous mapping when the setting changes is
unwarranted complexity.
For #71546.
Change-Id: I6a6a636c5ad551d76691cba2a6f668d5cff0e352
Reviewed-on: https://go-review.googlesource.com/c/go/+/655895
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Turns out that recomputing them (and qInv in particular) in constant
time is expensive, so let's not throw them away when they are available.
They are much faster to check, so we now do that on precompute.
Also, thanks to the opaque crypto/internal/fips140/rsa.PrivateKey type,
we now have some assurance that the values we use are always ones we
checked.
Recovers most of the performance loss since CL 630516 in the happy path.
Also, since now we always use the CRT, if necessary by running a
throwaway Precompute, which is now cheap if PrecomputedValues is filled
out, we effectively fixed the JSON round-trip slowdown (#59695).
goos: darwin
goarch: arm64
pkg: crypto/rsa
cpu: Apple M2
│ 3b42687c56 │ f017604bc6-dirty │
│ sec/op │ sec/op vs base │
ParsePKCS8PrivateKey/2048-8 26.76µ ± 1% 65.99µ ± 1% +146.64% (p=0.002 n=6)
Fixes#59695
Updates #69799
For #69536
Change-Id: I507f8c5a32e69ab28990a3bf78959836b9b08cc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/632478
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This makes three related changes that work particularly well together
and would require significant extra work to do separately: it replaces
X25519Kyber768Draft00 with X25519MLKEM768, it makes CurvePreferences
ordering crypto/tls-selected, and applies a preference to PQ key
exchange methods over key shares (to mitigate downgrades).
TestHandshakeServerUnsupportedKeyShare was removed because we are not
rejecting unsupported key shares anymore (nor do we select them, and
rejecting them actively is a MAY). It would have been nice to keep the
test to check we still continue successfully, but testClientHelloFailure
is broken in the face of any server-side behavior which requires writing
any other messages back to the client, or reading them.
Updates #69985Fixes#69393
Change-Id: I58de76f5b8742a9bd4543fd7907c48e038507b19
Reviewed-on: https://go-review.googlesource.com/c/go/+/630775
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add a new function, WithDataIndependentTiming, which takes a function as
an argument, and encloses it with calls to set/unset the DIT PSTATE bit
on Arm64.
Since DIT is OS thread-local, for the duration of the execution of
WithDataIndependentTiming, we lock the goroutine to the OS thread, using
LockOSThread. For long running operations, this is likely to not be
performant, but we expect this to be tightly scoped around cryptographic
operations that have bounded execution times.
If locking to the OS thread turns out to be too slow, another option is
to add a bit to the g state indicating if a goroutine has DIT enabled,
and then have the scheduler enable/disable DIT when scheduling a g.
Additionally, we add a new GODEBUG, dataindependenttiming, which allows
setting DIT for an entire program. Running a program with
dataindependenttiming=1 enables DIT for the program during
initialization. In an ideal world PSTATE.DIT would be inherited from
the parent thread, so we'd only need to set it in the main thread and
then all subsequent threads would inherit the value. While this does
happen in the Linux kernel [0], it is not the case for darwin [1].
Rather than add complex logic to only set it on darwin for each new
thread, we just unconditionally set it in mstart1 and cgocallbackg1
regardless of the OS. DIT will already impose some overhead, and the
cost of setting the bit is only ~two instructions (CALL, MSR), so it
should be cheap enough.
Fixes#66450
Updates #49702
[0] e8bdb3c8be/arch/arm64/kernel/process.c (L373)
[1] 8d741a5de7/osfmk/arm64/status.c (L1666)
Change-Id: I78eda691ff9254b0415f2b54770e5850a0179749
Reviewed-on: https://go-review.googlesource.com/c/go/+/598336
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This re-enables the behavior of CL 536399 (by effectively reverting CL
628955), so now go test -json again includes build output and failures
as JSON rather than text.
However, since this behavior is clearly enough to trip up some build
systems, this CL includes a GODEBUG=gotestjsonbuildtext that can be
set to 1 to revert to the old behavior.
Fixes#70402.
Updates #62067.
Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64_13,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I84e778cd844783dacfc83433e391b5ccb5925127
Reviewed-on: https://go-review.googlesource.com/c/go/+/629335
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Austin Clements <austin@google.com>
A GODEBUG is actually a security risk here: most programs will start to
ignore errors from Read because they can't happen (which is the intended
behavior), but then if a program is run with GODEBUG=randcrash=0 it will
use a partial buffer in case an error occurs, which may be catastrophic.
Note that the proposal was accepted without the GODEBUG, which was only
added later.
This (partially) reverts CL 608435. I kept the tests.
Updates #66821
Change-Id: I3fd20f9cae0d34115133fe935f0cfc7a741a2662
Reviewed-on: https://go-review.googlesource.com/c/go/+/622115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
A previous change [1] was introduced to enable MPTCP by default
for both the clients and servers, based on the discussions [2] in
golang#56539, where MPTCP would be an opt-in for a release or
two, and then would become an opt-out.
This change was not accepted at the time because the support for
a few socket options was missing [3]. Now that this support has been
added [4] and backported to stable versions not to block MPTCP
deployment with Go, it sounds like a good time to reconsider the use
of MPTCP by default.
Instead of enabling MPTCP on both ends by default, as a first step,
it seems safer to change the default behaviour only for the server
side (Listeners). On the server side, the impact is minimal: when
clients don't request to use MPTCP, server applications will create
"plain" TCP sockets within the kernel when connections are accepted,
making the performance impact minimal. This should also ease
experiments where MPTCP is enabled by default on the client side
(Dialer).
The changes in this patch consist of a duplication of the mptcpStatus
enumeration to have both a mptcpStatusDial and a mptcpStatusListen,
where MPTCP is enabled by default in mptcpStatusListen, but disabled
by default in mptcpStatusDial. It is still possible to turn MPTCP support
on and off by using GODEBUG=multipathtcp=1.
[1] https://go-review.googlesource.com/c/go/+/563575
[2] https://go.dev/issue/56539#issuecomment-1309294637
[3] https://github.com/multipath-tcp/mptcp_net-next/issues/383
[4] bd11dc4fb9
[5] https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default
Updates #56539
Change-Id: I1ca0d6aaf74d3bda5468af135e29cdb405d3fd00
GitHub-Last-Rev: 5f9f29bfc1
GitHub-Pull-Request: golang/go#69016
Reviewed-on: https://go-review.googlesource.com/c/go/+/607715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This reverts the changes to Error from CL 571995, and adds a
GODEBUG controlling the changes to ServeContent/ServeFile/ServeFS.
The change to remove the Content-Encoding header when serving an error
breaks middleware which sets Content-Encoding: gzip and wraps a
ResponseWriter in one which compresses the response body.
This middleware already breaks when ServeContent handles a Range request.
Correct uses of ServeContent which serve pre-compressed content with
a Content-Encoding: gzip header break if we don't remove that header
when serving errors. Therefore, we keep the change to ServeContent/
ServeFile/ServeFS, but we add the ability to disable the new behavior
by setting GODEBUG=httpservecontentkeepheaders=1.
We revert the change to Error, because users who don't want to include
a Content-Encoding header in errors can simply remove the header
themselves, or not add it in the first place.
Fixes#66343
Change-Id: Ic19a24b73624a5ac1a258ed7a8fe7d9bf86c6a38
Reviewed-on: https://go-review.googlesource.com/c/go/+/593157
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The fact that the go line sets both the language version and the
GODEBUG compatibility version can be a problem, especially since
the go line is also required to be ≥ the go lines of any required
dependency modules.
This change adds a new 'godebug' line to go.mod and go.work
to allow setting the GODEBUG values for the entire module.
It also adds a new meta-value default=go1.21 that means
take the defaults from Go 1.21 no matter what the go line says.
These were discussed in proposal #65573.
Fixes#65573.
Change-Id: I91746322a10178370ed1015ce5278372a024c824
Reviewed-on: https://go-review.googlesource.com/c/go/+/584476
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Per the note earlier in the page, GODEBUGs are maintained for a
minimum of two years (four Go releases). Not said but certainly
implied is that they are maintained for four Go releases from the
point where people started needing to use them.
Since people would start needing gotypesalias=0 in Go 1.23,
it can be removed in Go 1.27.
Change-Id: Ifad63a1fff63c3f96f2ee192ca74bd1ce8bdb61f
Reviewed-on: https://go-review.googlesource.com/c/go/+/585457
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
