chore(deps): update module github.com/opencontainers/runc to v1.3.6 [security]#146
Open
NumaryBot wants to merge 1 commit into
Open
chore(deps): update module github.com/opencontainers/runc to v1.3.6 [security]#146NumaryBot wants to merge 1 commit into
NumaryBot wants to merge 1 commit into
Conversation
Contributor
Author
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe indirect dependency ChangesDependency Upgrade
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
NumaryBot
commented
Jun 23, 2026
NumaryBot
left a comment
NumaryBot
left a comment
Contributor
Author
There was a problem hiding this comment.
🛑 Changes requested — automated review
The dependency bump is incomplete because the corresponding go.sum entry was not committed, which will make the existing tidy/dirty CI workflow fail.
| github.com/opencontainers/go-digest v1.0.0 // indirect | ||
| github.com/opencontainers/image-spec v1.1.1 // indirect | ||
| github.com/opencontainers/runc v1.2.8 // indirect | ||
| github.com/opencontainers/runc v1.3.6 // indirect |
Contributor
Author
There was a problem hiding this comment.
🔴 [blocker] Commit the updated runc checksum
With this version bump, go.sum still only contains the github.com/opencontainers/runc v1.2.8 entries and has no checksum for v1.3.6. The CI Dirty job runs just pre-commit, which includes go mod tidy, and that will add the missing v1.3.6 checksum before the subsequent git status check, causing the repository to be reported dirty; environments using readonly module mode can also fail on the missing sum.
flemzord
approved these changes
Jun 23, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR contains the following updates:
v1.2.8->v1.3.6runc: Malicious image with /dev symlink can trigger limited host filesystem integrity violations
CVE-2026-41579 / GHSA-xjvp-4fhw-gc47
More information
Details
Impact
When setting up the container rootfs,
setupPtmxandsetupDevSymlinkscallos.Removeandos.Symlinkwith afilepath.Joinstring which allow an image with/devas a symlink to trick runc into deleting files calledptmxon the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.Please note that this issue is not exploitable under Docker because it creates a top-level
rolayer that masks any malicious/devsymlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious/devsymlink to trick it into resolving to some other path). Unfortunately, Podman and containerd† do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.This issue mirrors a somewhat similar issue in crun, which was also published recently.
† Actually, at the time the issue was analysed, containerd had dead code that implemented this feature but the implementation contained several security issues that would arguably have made it more exploitable than in runc. Luckily, the code appears to have never been used (at least since 2017) and the code has since been removed.
Mitigating Factors
There are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.
While the deletion of
ptmxseems like a significant issue, in practice it is quite limited. Notably,devptsdoes not permit you to unlink/dev/pts/ptmxregardless of privileges and so it is not a usable target for this attack. Additionally, while/dev/ptmxcan be unlinked‡, trying to use an image with a symlink from/devto/devwill cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files calledptmxthat are guaranteed to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.As for the issue of symlinks, again the impact is likely quite limited. While the creation of arbitrary symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:
core→/proc/kcorefd→/proc/self/fd/ptmx→pts/ptmxstdin→/proc/self/fd/0stdout→/proc/self/fd/1stderr→/proc/self/fd/2Note that none of these symlinks are likely to point to user-controlled data -- the
/proc/self/fd/$nsymlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and thepts/ptmxsymlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as.conf) so it's not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.‡ This would actually be quite problematic if it could occur because
glibcseemingly only attempts to use/dev/ptmxwhen creating new terminals and thus most terminal managers (includingtmux) and shell tools (includingsudo-- but notsu) would fail to start and thus bring the system to a halt.setupPtmxdoes add a symlink to/dev/pts/ptmxafterwards but on some systems the mode of the host/dev/pts/ptmxis set to0o000which would still cause the same DoS issue.Patches
This issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.
Workarounds
Using user namespaces restricts this attack fairly significantly such that the attacker can only create/delete inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use
/etc/sub[ug]id), this in practice means that an attacker would only be able to create or delete inodes in world-writable directories.LSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default
container_runtime_tSELinux label rules (or custom AppArmor rules for the hostrunccontext) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.Resources
Credits
runc thanks "Davias" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu (@mosskappa), and Derek Manzella (@Dmanzella).
Severity
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
opencontainers/runc (github.com/opencontainers/runc)
v1.3.6: runc 1.3.6 -- "On no account should you allow a Vogon to read poetry at you."Compare Source
This is the sixth patch release of the 1.3.z series of runc. Among some
performance improvements and bugfixes, it includes a fix for a
low-severity vulnerability (CVE-2026-41579) and users are encouraged to
update. As it was a low-severity vulnerability and it was reported by
multiple people, we decided to release it publicly with NO EMBARGO.
Security
This release includes a fix for the following low-severity security issue:
CVE-2026-41579 allowed a malicious image with a
/devsymlink to havelimited write access to the host filesystem in ways that our analysis
indicates was too limited to be problematic in practice. This bug was very
similar to those fixed in CVE-2025-31133, CVE-2025-52565,
CVE-2025-31133 and was simply missed at the time when we hardened the
rootfs preparation code. We have conducted a deeper audit and not found any
other problematic cases.
This patchset required backports for #5190 and #5285, which were primarily
code reorganisations that were already backported to runc 1.4 and 1.5.
Fixed
runc execorrunc runwhen the container process runs for a short time. (#5208,#5210, #5215)
#5253, #5269, #5288)
Changed
maskPaths, runc will now re-use a singletmpfsinstance (which is not writable) to reduce the numbertmpfssuperblocks that need to be reaped when containers die (in particular,
Kubernetes applies masks to per-CPU sysfs directories which get expensive
quickly). (#5275, #5281)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
v1.3.5: runc v1.3.5 -- "Lo viejo funciona!"Compare Source
This is the fifth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for issues found in 1.3.4.
Fixed
properly. (#5115, #5098)
cannot start a container that has stoppederrors whenrunning
runc createand has thus been reverted. (#5158,#5153, #5151, #4645, #4757)
Changed
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
v1.3.4: runc v1.3.4 -- "Take me to your heart, take me to your soul."Compare Source
This is the fourth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for some regressions introduced in
1.3.3.
Fixed
tmpfsmount, only set themode=argument if thetarget path already existed. This fixes a regression introduced in our
CVE-2025-52881 mitigation patches. (#4971, #4976)
comprehensively as possible. (#5007, #5021, #5034)
Changed
github.com/cyphar/filepath-securejoindependency tov0.5.2,which should make it easier for some downstreams to import
runcwithoutpulling in too many extra packages. (#5028)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
v1.3.3: runc v1.3.3 -- "奴らに支配されていた恐怖を"Compare Source
This release contains fixes for three high-severity security
vulnerabilities in runc (CVE-2025-31133, CVE-2025-52565, and
CVE-2025-52881). All three vulnerabilities ultimately allow (through
different methods) for full container breakouts by bypassing runc's
restrictions for writing to arbitrary
/procfiles.Security
CVE-2025-31133 exploits an issue with how masked paths are implemented in
runc. When masking files, runc will bind-mount the container's
/dev/nullinode on top of the file. However, if an attacker can replace
/dev/nullwith a symlink to some other procfs file, runc will instead bind-mount the
symlink target read-write. This issue affected all known runc versions.
CVE-2025-52565 is very similar in concept and application to
CVE-2025-31133, except that it exploits a flaw in
/dev/consolebind-mounts. When creating the
/dev/consolebind-mount (to/dev/pts/$n),if an attacker replaces
/dev/pts/$nwith a symlink then runc willbind-mount the symlink target over
/dev/console. This issue affected allversions of runc >= 1.0.0-rc3.
CVE-2025-52881 is a more sophisticated variant of CVE-2019-19921,
which was a flaw that 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 we
applied for CVE-2019-19921 was fairly limited and effectively only caused
runc to verify that when we write LSM labels that those labels are actual
procfs files. This issue affects all known runc versions.
Added
runc updatenow supports configuring per-device weights and iops. (#4775,#4807, #4825, #4931)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
v1.3.2: runc v1.3.2 -- "Ночь, улица, фонарь, аптека..."Compare Source
This is the second patch release of the 1.3.z release series of runc.
It primarily includes some minor fixes for issues found in 1.3.1.
Changed:
improved to better fit default v1 and v2 values. (#4772, #4785, #4897)
v0.0.4. (#4897)
Fixed:
(#4798, #4808, #4897)
kernel was rounding memory limit to 64K. (#4841, #4895, #4893)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors who made this release possible:
Signed-off-by: Kir Kolyshkin kolyshkin@gmail.com
v1.3.1: runc v1.3.1 -- "この瓦礫の山でよぉ"Compare Source
This is the first patch release of the 1.3.z release series of runc. It
primarily includes some minor fixes for issues found in 1.3.0.
Fixed
default. Instead, the default CPU affinity of container processes will be
the largest set of CPUs permitted by the container's cpuset cgroup and any
other system restrictions (such as isolated CPUs). (#4041, #4815, #4858)
linux.rootfsPropagationtosharedorunbindablenow functionsproperly. (#1755, #1815, #4724, #4789)
runc deleteandrunc stopcan now correctly handle cases whererunc createwas killed during setup. Previously it was possible for thecontainer to be in such a state that neither
runc stopnorrunc deletewould be unable to kill or delete the container. (#4534, #4645, #4757,
#4788)
runc updatewill no longer clear intelRdt state information. (#4828,#4833)
Changed
github.com/opencontainers/cgroupssplit. (#4784, #4788)support it. (#4806, #4811)
/proc/net/devis no longer included in the permitted procfs overmountlist. Its inclusion was almost certainly an error, and because
/proc/netis a symlink to
/proc/self/net, overmounting this was almost certainlynever useful (and will be blocked by future kernel versions). (#4817, #4820)
prepareCriuRestoreMountslogic for checkpoint-restore.(#4765, #4871)
golangci-lintto v2.1. (#4747, #4754)supporting runc's ARM CI up until now. (#4844, #4856, #4867)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors who made this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
v1.3.0: runc v1.3.0 -- "Mr. President, we must not allow a mine shaft gap!"Compare Source
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:
receive security and "significant" bugfixes.
possible.
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.
a runc 1.4.0 release in late October 2025.
Fixed
runc pauseorrunc unpauseas an unprivileged user without--systemd-cgroups. Now the warning is only emitted if an actual permissionerror was encountered. (#4709)
#4728, #4736)
Changed
flags. However, the error messages we returned did not provide as much
information to users about what clearing flags were conflicting with locked
mount flags. We now provide more diagnostic information if there is an error
when in the fallback path to handle locked mount flags. (#4734)
runc versioninformation is now filled in using//go:embedrather thanbeing set through
Makefile. This allowsgo installor other non-makebuilds to contain the correct version information. Note that
make EXTRA_VERSION=...still works. (#418)excludedirectives from ourgo.modfor brokencilium/ebpfversions.
v0.17.3resolved the issue we had, andexcludedirectives areincompatible with
go install. (#4748)Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
v1.2.9: runc v1.2.9 -- "Stars hide your fires, let me rest tonight."Compare Source
This is the ninth patch release of the 1.2.z release series of runc, and
primarily contains a few fixes for some regressions introduced in 1.2.8.
Fixed
tmpfsmount, only set themode=argument if thetarget path already existed. This fixes a regression introduced in our
CVE-2025-52881 mitigation patches. (#4971, #4974)
comprehensively as possible. (#5007, #5021, #5027)
Changed
github.com/cyphar/filepath-securejoindependency tov0.5.2,which should make it easier for some downstreams to import
runcwithoutpulling in too many extra packages. (#5027)
Static Linking Notices
The
runcbinary distributed with this release are statically linked withthe following GNU LGPL-2.1 licensed libraries, with
runcactingas a "work that uses the Library":
The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.
However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.
Thanks to the following contributors for making this release possible:
Signed-off-by: Aleksa Sarai cyphar@cyphar.com
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Renovate Bot.
Summary by CodeRabbit