This change updates the Go version from 1.26.0 to 1.26.2 across the
repository, including CI configurations, build scripts, and development
environments.
Signed-off-by: Sergey Kanzhelev <S.Kanzhelev@live.com>
This change updates the Go version from 1.25.8 to 1.26.0 across the
repository, including CI configurations, build scripts, and development
environments.
It also fixes two linter issues discovered after upgrading the Go version:
- core/snapshots/storage/bolt.go: incorrect printf format for uint64
- plugins/transfer/plugin.go: incorrect printf format for int and unused variable
The golangci-lint version in script/setup/install-dev-tools is also updated to v2.9.0
to match CI.
Signed-off-by: Sergey Kanzhelev <S.Kanzhelev@live.com>
Updates crun version used by integration tests to 1.27 and enables the
test for cgroup mount options in
TestPrivilegedContainerCgroupMountOptions.
Assisted-by: Antigravity
Signed-off-by: Chris Henzie <chrishenzie@gmail.com>
This change updates the version of cri-tools used for testing from
v1.33.0 to v1.35.0 in script/setup/critools-version.
It also updates the hardcoded download URL for crictl in
script/setup/prepare_env_windows.ps1 from v1.26.0 to v1.35.0.
Signed-off-by: Sergey Kanzhelev <S.Kanzhelev@live.com>
go1.25.8 (released 2026-03-05) includes security fixes to the html/template,
net/url, and os packages, as well as bug fixes to the go command, the compiler,
and the os package. See the Go 1.25.8 milestone on our issue tracker for details.
- 1.25.8 https://github.com/golang/go/issues?q=milestone%3AGo1.25.8+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.25.7...go1.25.8
- 1.26.1 https://github.com/golang/go/issues?q=milestone%3AGo1.26.1+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.26.0...go1.26.1
---
We have just released Go versions 1.26.1 and 1.25.8, minor point releases.
These releases include 5 security fixes following the security policy:
crypto/x509: incorrect enforcement of email constraints
- When verifying a certificate chain which contains a certificate containing
multiple email address constraints (composed of the full email address) which
share common local portions (the portion of the address before the '@'
character) but different domain portions (the portion of the address after the
'@' character), these constraints will not be properly applied, and only the
last constraint will be considered.
This can allow certificates in the chain containing email addresses which are
either not permitted or excluded by the relevant constraints to be returned by
calls to Certificate.Verify. Since the name constraint checks happen after chain
building is complete, this only applies to certificate chains which chain to
trusted roots (root certificates either in VerifyOptions.Roots or in the system
root certificate pool), requiring a trusted CA to issue certificates containing
either not permitted or excluded email addresses.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27137 and Go issue https://go.dev/issue/77952.
- crypto/x509: panic in name constraint checking for malformed certificates
Certificate verification can panic when a certificate in the chain has an empty
DNS name and another certificate in the chain has excluded name constraints.
This can crash programs that are either directly verifying X.509 certificate
chains, or those that use TLS.
Since the name constraint checks happen after chain building is complete, this
only applies to certificate chains which chain to trusted roots (root
certificates either in VerifyOptions.Roots or in the system root certificate
pool), requiring a trusted CA to issue certificates containing malformed DNS
names.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27138 and Go issue https://go.dev/issue/77953.
- html/template: URLs in meta content attribute actions are not escaped
Actions which insert URLs into the content attribute of HTML meta tags are not
escaped. This can allow XSS if the meta tag also has an http-equiv attribute
with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be
used to disable escaping URLs in actions in the meta content attribute which
follow "url=" by setting htmlmetacontenturlescape=0.
This is CVE-2026-27142 and Go issue https://go.dev/issue/77954.
- net/url: reject IPv6 literal not at start of host
The Go standard library function net/url.Parse insufficiently
validated the host/authority component and accepted some invalid URLs
by effectively treating garbage before an IP-literal as ignorable.
The function should have rejected this as invalid.
To prevent this behavior, net/url.Parse now rejects IPv6 literals
that do not appear at the start of the host subcomponent of a URL.
Thanks to Masaki Hara (https://github.com/qnighy) of Wantedly.
This is CVE-2026-25679 and Go issue https://go.dev/issue/77578.
- os: FileInfo can escape from a Root
On Unix platforms, when listing the contents of a directory using
File.ReadDir or File.Readdir the returned FileInfo could reference
a file outside of the Root in which the File was opened.
The contents of the FileInfo were populated using the lstat system
call, which takes the path to the file as a parameter. If a component
of the full path of the file described by the FileInfo is replaced with
a symbolic link, the target of the lstat can be directed to another
location on the filesystem.
The impact of this escape is limited to reading metadata provided by
lstat from arbitrary locations on the filesystem. This could be used
to probe for the presence or absence of files as well as gleaning
metadata like file sizes, but does not permit reading or writing files
outside the root.
The FileInfo is now populated using fstatat.
Thank you to Miloslav Trmač of Red Hat for reporting this issue.
This is CVE-2026-27139 and Go issue https://go.dev/issue/77827.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.25.7 (released 2026-02-04) includes security fixes to the go command
and the crypto/tls package, as well as bug fixes to the compiler and the
crypto/x509 package. See the Go 1.25.7 milestone on our issue tracker for
details:
https://github.com/golang/go/issues?q=milestone%3AGo1.25.7+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.25.6...go1.25.7
From the security mailing list:
> Hello gophers,
>
> We have just released Go versions 1.25.7 and 1.24.13, minor point releases.
>
> These releases include 2 security fixes following the security policy:
>
> - cmd/cgo: remove user-content from doc strings in cgo ASTs
>
> A discrepancy between how Go and C/C++ comments
> were parsed allowed for code smuggling into the
> resulting cgo binary.
>
> To prevent this behavior, the cgo compiler
> will no longer parse user-provided doc
> comments.
>
> Thank you to RyotaK (https://ryotak.net) of
> GMO Flatt Security Inc. for reporting this issue.
>
> This is CVE-2025-61732 and https://go.dev/issue/76697.
>
> - crypto/tls: unexpected session resumption when using Config.GetConfigForClient
>
> Config.GetConfigForClient is documented to use the original Config's session
> ticket keys unless explicitly overridden. This can cause unexpected behavior if
> the returned Config modifies authentication parameters, like ClientCAs: a
> connection initially established with the parent (or a sibling) Config can be
> resumed, bypassing the modified authentication requirements.
>
> If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on the
> server) or InsecureSkipVerify is false (on the client), crypto/tls now checks
> that the root of the previously-verified chain is still in ClientCAs/RootCAs
> when resuming a connection.
>
> Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar issue
> related to session ticket keys being implicitly shared by Config.Clone. Since
> this fix is broader, the Config.Clone behavior change has been reverted.
>
> Note that VerifyPeerCertificate still behaves as documented: it does not apply
> to resumed connections. Applications that use Config.GetConfigForClient or
> Config.Clone and do not wish to blindly resume connections established with the
> original Config must use VerifyConnection instead (or SetSessionTicketKeys or
> SessionTicketsDisabled).
>
> Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
>
> This updates CVE-2025-68121 and Go issue https://go.dev/issue/77217.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
v1.4.0 is the first release of the 1.4 release branch which is now
encouraged by the maintainers.
This update includes a fix for a regression introduced in CVE-2025-52881
mitigation patches where the `mode=` argument was incorrectly applied to
tmpfs mounts regardless of whether the target path existed.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
No idea why it blames lock during fetching.
```bash
...
* [new tag] v0.9.9 -> v0.9.9
error: cannot lock ref 'refs/tags/v0.6.3': Unable to create 'C:/Users/runneradmin/AppData/Local/Temp/tmp.N2FTxfARN9/.git/refs/tags/v0.6.3.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
+ cleanup
+ rm -rf /tmp/tmp.N2FTxfARN9
```
Signed-off-by: Wei Fu <fuweid89@gmail.com>
This is the first release of the 1.3.z release branch of runc. It
contains a few minor fixes for issues found in 1.3.0-rc.2.
This is the first release of runc that will follow our new release and
support policy (see RELEASES.md for more details). This means that, as
of this release:
As of this release, the runc 1.2.z release branch will now only
receive security and "significant" bugfixes.
Users are encouraged to plan migrating to runc 1.3.0 as soon as
possible.
Due to its particular situation, runc 1.1.z is officially no longer
supported and will no longer receive any updates (not even for
critical security issues). Users are urged (in the strongest possible
terms) to upgrade to a supported version of runc.
Barring any future changes to our release policy, users should expect
a runc 1.4.0 release in late October 2025.
full diff: https://github.com/opencontainers/runc/compare/v1.2.6...v1.3.0
Signed-off-by: Austin Vazquez <austin.vazquez.dev@gmail.com>
- go1.23.7 (released 2025-03-04) includes security fixes to the net/http
package, as well as bug fixes to cgo, the compiler, and the reflect,
runtime, and syscall packages. See the Go 1.23.7 milestone on our issue
tracker for details
- go1.24.1 (released 2025-03-04) includes security fixes to the net/http
package, as well as bug fixes to cgo, the compiler, the go command, and
the reflect, runtime, and syscall packages. See the Go 1.24.1 milestone
on our issue tracker for details.
Signed-off-by: Akhil Mohan <akhilerm@gmail.com>
This is the fifth patch release in the 1.2.z series of runc. It
primarily fixes an issue caused by an upstream systemd bug.
There was a regression in systemd v230 which made the way we define device
rule restrictions require a systemctl daemon-reload for our transient
units. This caused issues for workloads using NVIDIA GPUs. Workaround the
upstream regression by re-arranging how the unit properties are defined.
Dependency github.com/cyphar/filepath-securejoin is updated to v0.4.1,
to allow projects that vendor runc to bump it as well.
CI: fixed criu-dev compilation.
Dependency golang.org/x/net is updated to 0.33.0.
diff: opencontainers/runc@v1.2.4...v1.2.5
Signed-off-by: Austin Vazquez <macedonv@amazon.com>
Adds a new diff plugin that can import image layers in the block CIM format using the new
block CIM layer writer added in hcsshim repo.
This commit also makes another important change in the way a diff is applied when using
CimFS based layer writers. Currently, the diff plugins call archive.Apply to apply a diff
and pass a function (that can actually apply the diff) as an argument (via
archive.ApplyOptions). This allows the callers to call archive.Apply with either a custom
applier function or if the caller doesn't pass such a function archive.Apply uses the
default naive diff applier.
However, there is drawback to this approach. The applier function passed to the
`archive.Apply` call needs to follow a specific signature. This signature expects it that
all parent layers are represented as an array of strings. In cases like CimFS, we can't
easily represent a set of layers as strings (unless we encode extra data in those strings
in a hacky way). To get around this problem, the diff plugins for CimFS based layers, skip
the archive.Apply call and directly call the layer writer instead.
Signed-off-by: Amit Barve <ambarve@microsoft.com>
