This releases includes 6 security fixes following the security policy:
- archive/zip: denial of service when parsing arbitrary ZIP archives
archive/zip used a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.
Thanks to Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61728 and Go issue https://go.dev/issue/77102.
- net/http: memory exhaustion in Request.ParseForm
When parsing a URL-encoded form net/http may allocate an unexpected amount of
memory when provided a large number of key-value pairs. This can result in a
denial of service due to memory exhaustion.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-61726 and Go issue https://go.dev/issue/77101.
- crypto/tls: Config.Clone copies automatically generated session ticket keys, session resumption does not account for the expiration of full certificate chain
The Config.Clone methods allows cloning a Config which has already been passed
to a TLS function, allowing it to be mutated and reused.
If Config.SessionTicketKey has not been set, and Config.SetSessionTicketKeys has
not been called, crypto/tls will generate random session ticket keys and
automatically rotate them. Config.Clone would copy these automatically generated
keys into the returned Config, meaning that the two Configs would share session
ticket keys, allowing sessions created using one Config could be used to resume
sessions with the other Config. This can allow clients to resume sessions even
though the Config may be configured such that they should not be able to do so.
Config.Clone no longer copies the automatically generated session ticket keys.
Config.Clone still copies keys which are explicitly provided, either by setting
Config.SessionTicketKey or by calling Config.SetSessionTicketKeys.
This issue was discoverd by the Go Security team while investigating another
issue reported by Coia Prant (github.com/rbqvq).
Additionally, on the server side only the expiration of the leaf certificate, if
one was provided during the initial handshake, was checked when considering if a
session could be resumed. This allowed sessions to be resumed if an intermediate
or root certificate in the chain had expired.
Session resumption now takes into account of the full chain when determining if
the session can be resumed.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-68121 and Go issue https://go.dev/issue/77113.
- cmd/go: bypass of flag sanitization can lead to arbitrary code execution
Usage of 'CgoPkgConfig' allowed execution of the pkg-config
binary with flags that are not explicitly safe-listed.
To prevent this behavior, compiler flags resulting from usage
of 'CgoPkgConfig' are sanitized prior to invoking pkg-config.
Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc.
for reporting this issue.
This is CVE-2025-61731 and go.dev/issue/77100.
- cmd/go: unexpected code execution when invoking toolchain
The Go toolchain supports multiple VCS which are used retrieving modules and
embedding build information into binaries.
On systems with Mercurial installed (hg) downloading modules (e.g. via go get or
go mod download) from non-standard sources (e.g. custom domains) can cause
unexpected code execution due to how external VCS commands are constructed.
On systems with Git installed, downloading and building modules with malicious
version strings could allow an attacker to write to arbitrary files on the
system the user has access to. This can only be triggered by explicitly
providing the malicious version strings to the toolchain, and does not affect
usage of @latest or bare module paths.
The toolchain now uses safer VCS options to prevent misinterpretation of
untrusted inputs. In addition, the toolchain now disallows module version
strings prefixed with a "-" or "/" character.
Thanks to splitline (@splitline) from DEVCORE Research Team for reporting this
issue.
This is CVE-2025-68119 and Go issue https://go.dev/issue/77099.
- crypto/tls: handshake messages may be processed at the incorrect encryption level
During the TLS 1.3 handshake if multiple messages are sent in records that span
encryption level boundaries (for instance the Client Hello and Encrypted
Extensions messages), the subsequent messages may be processed before the
encryption level changes. This can cause some minor information disclosure if a
network-local attacker can inject messages during the handshake.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-61730 and Go issue https://go.dev/issue/76443
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Minor enhancement / follow-up to c8aaeea285c63f9add09e01bd8260d1bce61a97d;
make sure we never attempt to find `go.mod` files in other locations.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add the nri_no_wasm build tag to the BUILDFLAGS for static builds to
disable WASM plugins support in the NRI (Node Resource Interface)
component.
See: 1078130fa0/README.md (webassembly-support)
The NRI support is still minimal and disabling WASM plugins shaves off a
couple of MiB of the binary size.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This option was added in 9672afa339 in 2016,
at which time tweaking GOGC showed a significant difference when building
the binary (`1m14.221s` vs `0m49.929s`).
Testing this Today doesn't show a real difference;
With GOGC=1000:
rm -rf bundles/
time hack/make.sh binary
real 0m15.303s
user 0m26.285s
sys 0m6.383s
real 0m4.931s
user 0m3.103s
sys 0m1.670s
real 0m5.693s
user 0m3.827s
sys 0m2.384s
Without GOGC set;
real 0m5.012s
user 0m3.689s
sys 0m1.549s
real 0m5.298s
user 0m3.997s
sys 0m1.695s
real 0m4.899s
user 0m3.579s
sys 0m1.423s
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove the `replace` rule check as it's not needed because it will also
pass the second check.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
dropreplace now accepts an optional argument that allows to manually
specify a git ref to use for the modules.
It's not required though and if not present it will default to a master
branch from the upstream (preferred) or origin remote.
This is much more reliable than "module@master" which for some reason
tends to not resolve to the actual latest commit on the master branch.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Add a `dev` target which adds a convenient developer loop which
rebuilds and reruns the daemon after a SIGINT is received.
It can be exited by sending SIGINT (Ctrl+C) a couple times.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The directory was solely used by Dockerfile.simple.
For the "simple" mode, we can just directly apt-get the dependencies.
A part of issue 51637
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
These releases include 2 security fixes following the security policy:
- crypto/x509: excessive resource consumption in printing error string for host certificate validation
Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out.
Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime.
Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.
HostnameError.Error() now limits the number of hosts and utilizes strings.Builder when constructing an error string.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61729 and Go issue https://go.dev/issue/76445.
- crypto/x509: excluded subdomain constraint does not restrict wildcard SANs
An excluded subdomain constraint in a certificate chain does not restrict the
usage of wildcard SANs in the leaf certificate. For example a constraint that
excludes the subdomain test.example.com does not prevent a leaf certificate from
claiming the SAN *.example.com.
This is CVE-2025-61727 and Go issue https://go.dev/issue/76442.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Do not require replace rules to be added if there's no code-changes
in the module. Note that changes in api/swagger.yaml may result in
changes in generated code, but this should be checked separate from
the swagger itself.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The bash array usage was wrong - change to a simpler check that just
compares if the diff is empty.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Running sub-package tests from the root module without readding the
replace rules wasn't running the tests from the local in-tree versions
of these submodules.
Fix by cd-ing into their directories before running tests.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Update the version of containerd used in CI and for static binaries
to v2.1.5 (linux) and v2.0.7 (windows)
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
This change adds type specific fields to `GET /system/df` endpoint with high level information of disk usage. This change also introduces `verbose` query to the endpoint so that detailed information is by default excluded unless queried to reduce memory consumption. The previous top level `DiskUsage` fields (`Images`, `Containers`, `Volumes` and `BuildCache`) are now deprecated and kept for backwards compatibility.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
Now that we're raising the minimum API version, we can also update
the CLI used in our integration-cli tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 081987b647 updated the Dockerfile
to disable go's telemetry in our dev / test-environment; as collecting
this data doesn't serve much purpose.
However, the configuration to disable telemetry is tied to the user's
home-directory (HOME); and disabling telemetry writs a config-file to the
user's home-directory (`~/.config/go/telemetry/mode`). While go provides
env-vars about the mode and location (`GOTELEMETRY` and `GOTELEMETRYDIR`),
those env-vars are read-only and cannot be used to either disable telemetry
or to set the location;
> Information about telemetry configuration is also available via read-only Go environment variables:
>
> go env GOTELEMETRY reports the telemetry mode.
> go env GOTELEMETRYDIR reports the directory holding telemetry configuration and data.
Some steps in our CI set up a different home-directory, which is not configured
to disable telemetry, which means that CI currently leaves behind a bunch of
files related to this;
make TEST_FILTER=TestPruneDontDeleteUsedDangling test-integration
tree -a bundles/test-integration/fake-HOME/
bundles/test-integration/fake-HOME/
└── .config
└── go
└── telemetry
├── local
│ ├── asm@go1.25.3-go1.25.3-linux-arm64-2025-10-21.v1.count
│ ├── compile@go1.25.3-go1.25.3-linux-arm64-2025-10-21.v1.count
│ ├── go@go1.25.3-go1.25.3-linux-arm64-2025-10-21.v1.count
│ ├── link@go1.25.3-go1.25.3-linux-arm64-2025-10-21.v1.count
│ ├── test2json@go1.25.3-go1.25.3-linux-arm64-2025-10-21.v1.count
│ ├── upload.token
│ └── weekends
└── upload
6 directories, 7 files
This patch disables go telemetry also for this home-directory to prevent
those files from being created, and to prevent go from producing the
telemetry.
With this patch, only the file to disable telemetry is produced:
make TEST_FILTER=TestPruneDontDeleteUsedDangling test-integration
tree -a bundles/test-integration/fake-HOME/
bundles/test-integration/fake-HOME/
└── .config
└── go
└── telemetry
└── mode
4 directories, 1 file
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
