You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The ParseAddress function constructeds domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.
Affected range
<1.24.8
Fixed version
1.24.8
Description
The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.
This affects programs which parse untrusted PEM inputs.
Affected range
<1.24.8
Fixed version
1.24.8
Description
Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.
This affects programs which validate arbitrary certificate chains.
Affected range
<1.24.9
Fixed version
1.24.9
Description
Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.
This affects programs which validate arbitrary certificate chains.
Affected range
>=1.24.0 <1.24.6
Fixed version
1.24.6
Description
If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.
Affected range
<1.24.8
Fixed version
1.24.8
Description
The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.
Affected range
<1.24.8
Fixed version
1.24.8
Description
When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.
Affected range
<1.24.8
Fixed version
1.24.8
Description
Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.
Affected range
<1.24.8
Fixed version
1.24.8
Description
Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.
Affected range
<1.24.8
Fixed version
1.24.8
Description
The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.
Affected range
<1.24.8
Fixed version
1.24.8
Description
tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.
An overly broad default permission vulnerability was found in containerd.
/var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
Allowed local users on the host to potentially access the metadata store and the content store
/run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
/run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700
The directory paths may differ depending on the daemon configuration.
When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.
Patches
This bug has been fixed in the following containerd versions:
2.2.0
2.1.5
2.0.7
1.7.29
Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.
[!NOTE]
/run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711.
This is an expected behavior for supporting userns-remapped containers.
Workarounds
The system administrator on the host can manually chmod the directories to not
have group or world accessible permisisons:
An overly broad default permission vulnerability was found in containerd.
/var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
Allowed local users on the host to potentially access the metadata store and the content store
/run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
/run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700
The directory paths may differ depending on the daemon configuration.
When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.
Patches
This bug has been fixed in the following containerd versions:
2.2.0
2.1.5
2.0.7
1.7.29
Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.
[!NOTE]
/run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711.
This is an expected behavior for supporting userns-remapped containers.
Workarounds
The system administrator on the host can manually chmod the directories to not
have group or world accessible permisisons:
This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy tmpfs file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.
Rather than using a fake tmpfs file for /proc/self/attr/<label>, an attacker could instead (through various means) make /proc/self/attr/<label> reference a real procfs file, but one that would still be a no-op (such as /proc/self/sched). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.
In all known versions of runc, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts.
Note that while /proc/self/attr/<label> was the example used above (which is LSM-specific), this issue affect all writes to /proc in runc and thus also affects sysctls (written to /proc/sys/...) and some other APIs.
Additional Impacts
While investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as /proc/sysrq-trigger rather than just no-op files like /proc/self/sched. For instance, the default AppArmor profile name in Docker is docker-default, which when written to /proc/sysrq-trigger would cause the host system to crash.
When this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to /proc/sys/kernel/core_pattern and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to /proc/sysrq-trigger) can easily cause the machine to hang.
Note that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.
Patches
This advisory is being published as part of a set of three advisories:
CVE-2025-31133
CVE-2025-52881
CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:
77d217c7c377 ("init: write sysctls using safe procfs API")
435cc81be6b7 ("init: use securejoin for /proc/self/setgroups")
d61fd29d854b ("libct/system: use securejoin for /proc/$pid/stat")
4b37cd93f86e ("libct: align param type for mountCgroupV1/V2 functions")
d40b3439a961 ("rootfs: switch to fd-based handling of mountpoint targets")
ed6b1693b8b3 ("selinux: use safe procfs API for labels")
Please note that this patch includes a private patch for github.com/opencontainers/selinux that could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).
The patch includes a complete copy of the forked code and a replace directive (as well as go mod vendor applied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.
3f925525b44d ("rootfs: re-allow dangling symlinks in mount targets")
a41366e74080 ("openat2: improve resilience on busy systems")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched.
Mitigations
Do not run untrusted container images from unknown or unverified sources.
For the basic no-op attack, this attack allows a container process to run with the same LSM labels as runc. For most AppArmor deployments this means it will be unconfined, and for SELinux it will likely be container_runtime_t. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup.
For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including /proc/sysrq-trigger) and so LSMs likely do not provide much protection against these attacks.
Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the runc process is executing as cannot write to the aforementioned procfs files (even intentionally).
Other Runtimes
As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.
Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host's /proc for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container's procfs to avoid CVE-2016-9962-style attacks).
Credits
Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.
Additional thanks go to Tõnis Tiigi for finding some very useful exploit templates for these kinds of race attacks using docker buildx build.
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.
Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.
Impact
The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".
When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.
Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.
Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.
Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.
Patches
Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
nicholasdille-bot
left a comment
This PR contains the following updates:
0.3.224->0.3.226Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
superfly/flyctl (superfly/flyctl)
v0.3.226Compare Source
Changelog
39c7a71Revert "Remove GraphQL from deploy command" (#4691)3869006Fix fly secrets multiline (#4688)v0.3.225Compare Source
Changelog
937cbaeBump actions/setup-go from 5 to 6 (#4689)48bec95Add a development environment variable for platform build target (#4690)43c91b2Remove GraphQL from deploy command (#4684)Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.