fix(deps): update module github.com/opencontainers/runc to v1.2.8 [security] (v1.4) #4298

cilium-renovate · 2025-11-06T08:10:58Z

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/opencontainers/runc	`v1.2.5` -> `v1.2.8`

Container escape and DDoS due to arbitrary write gadgets and procfs write redirects in github.com/opencontainers/runc

CVE-2025-52881 / GHSA-cgrx-mc8f-2prm / GO-2025-4098

More information

Details

Container escape and DDoS due to arbitrary write gadgets and procfs write redirects in github.com/opencontainers/runc

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Container escape via "masked path" abuse due to mount race conditions in github.com/opencontainers/runc

CVE-2025-31133 / GHSA-9493-h29p-rfm2 / GO-2025-4096

More information

Details

Container escape via "masked path" abuse due to mount race conditions in github.com/opencontainers/runc

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

runc container escape with malicious config due to /dev/console mount and related races

CVE-2025-52565 / GHSA-qw9x-cqr3-wc7r / GO-2025-4097

More information

Details

Impact

This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of /dev/pts/$n to /dev/console as configured for all containers that allocate a console).

In runc version 1.0.0-rc3 and later, due to insufficient checks when bind-mounting /dev/pts/$n to /dev/console inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This happens after pivot_root(2), so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of /proc/sysrq-trigger or /proc/sys/kernel/core_pattern (respectively).

The reason that the attacker can gain write access to these files is because the /dev/console bind-mount happens before maskedPaths and readonlyPaths are applied.

Additional Findings

While investigating this issue, runc discovered some other theoretical issues that may or may not be exploitable, as well as taking the opportunity to fix some fairly well-known issues related to consoles.

Issue 1: Problematic Usage of `os.Create`

Go provides an os.Create function for creating files, which older code in runc (dating back to the original libcontainer from the early 2010s) had a tendency to use fairly liberally. os.Create implies O_CREAT|O_TRUNC but by design it does not apply O_NOFOLLOW nor O_EXCL, meaning if the target is swapped with a malicious symlink runc can be tricked into truncating host files (which can lead to denial of service attacks, among other concerns).

Runc conducted an audit of all os.Create usages in runc and found some suspicious usages related to device inodes, but based on runc's testing these were not exploitable in practice. Runc now has custom code lints to block any os.Create usage in runc, and plan to do a further audit of any other plain os.* operation usage throughout runc after this advisory becomes public.

CVE-2024-45310 was a similar attack but without the O_TRUNC component (which resulted in a "Low" severity) -- a similar attack being exploitable would've been much more severe.

Issue 2: Malicious `/dev/pts/$n` Inode Attacks (`TIOCGPTPEER`)

The (very) classic API for constructing consoles involves first opening /dev/ptmx for reading and writing. This allocates a new pseudo-terminal and the returned file descriptor is the "master" end (which is used by higher-level runtimes to do I/O with the container).

Traditionally, in order to get the "slave" end, you do ioctl(ptm, TIOCGPTN) to get the pseudo-terminal number and then open the file in /dev/pts/ with the corresponding base-10 decimal number of the number returned by TIOCGPTN. The naive way of doing this is vulnerable to very basic race attacks where /dev/pts/$n is replaced with a different pseudo-terminal or other malicious file.

In order to provide a mechanism to mitigate this risk, Aleksa Sarai (@cyphar from SUSE) implemented TIOCGPTPEER back in 2017 to provide a race-free way of doing the last TIOCGPTN step by opening the peer end of the pseudo-terminal directly. However, at the time it was believed to be too impractical to implement this protection in runc due to its no-monitor-process architecture (unlike runtimes like LXC which made use of TIOCGPTPEER almost immediately). While working on this advisory, runc found a way to make TIOCGPTN usage on pre-4.13 kernels still safe against race attacks and so have implemented both TIOCGPTPEER support as well as safe TIOCGPTN support as a fallback.

Another possible target of attack would be replacing /dev/ptmx or /dev/pts/ptmx with a different inode and tricking runc into trying to operate on it. This is very similar to the core issue in CVE-2025-31133 and had a similar solution.

Runc's analysis was that while this attack appears to be potentially problematic in theory, it seems unlikely to actually be exploitable due to how consoles are treated (runc tries to do several pseudo-terminal-specific ioctls and will error out if they fail -- which happens for most other file types). In principle you could imagine a DoS attack using a disconnected NFS handle but it seems impractical to exploit. However, runc felt it prudent to include a solution (and this also provides a safe mechanism to get the source mount for the /dev/console bind-mount issue at the beginning of this advisory).

Patches

This advisory is being published as part of a set of three advisories:

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:

db19bbed5348 ("internal/sys: add VerifyInode helper")
ff94f9991bd3 ("*: switch to safer securejoin.Reopen")
531ef794e4ec ("console: use TIOCGPTPEER when allocating peer PTY")
398955bccb7f ("console: add fallback for pre-TIOCGPTPEER kernels")
9be1dbf4ac67 ("console: avoid trivial symlink attacks for /dev/console")
de87203e625c ("console: verify /dev/pts/ptmx before use")
01de9d65dc72 ("rootfs: avoid using os.Create for new device inodes")
aee7d3fe355d ("ci: add lint to forbid the usage of os.Create")

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

Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the procfs files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.

An attacker would still be able to bind-mount host paths into the container but if the host uids and gids mapped into the container do not overlap with ordinary users on the host (which is the generally recommended configuration) then the attacker would likely not be able to read or write to most sensitive host files (depending on the Unix DAC permissions of the host files). Note that this is still technically more privilege than an unprivileged user on the host -- because the bind-mount is done by a privileged process, the attacker would be able to get access to directories whose parents may have denied search access (i.e., they may be able to access paths inside a chmod 700 directory that would normally block them from resolving subpaths).

Runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONE_NEWUSER) inside containers regardless of whether the container itself uses user namespaces.

Rootless containers can provide even more protection if your configuration can use them -- 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 non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling noNewPrivileges to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use ping in your containers, there is a net.ipv4.ping_group_range sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries.
Do not run untrusted container images from unknown or unverified sources.
The default containers-selinux SELinux policy mitigates this issue, as (unlike CVE-2025-31133) the /dev/console bind-mount does not get relabeled and so the container process cannot write to the bind-mounted procfs file by default.

Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881.
The default AppArmor policy used by Docker and Podman does not mitigate this issue (as access to /dev/console) is usually permitted. Users could create a custom profile that blocks access to /dev/console, but such a profile might break regular containers.

Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so the mitigation provided with a custom profile is not that helpful when considered in combination with CVE-2025-52881.

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 also be vulnerable in some aspects, but their security stance is (understandably) that non-user-namespaced containers are fundamentally insecure by design.

Credits

Thanks to Lei Wang (@ssst0n3 from Huawei) and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering and reporting the main /dev/console bind-mount vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for discovering Issues 1 and 2 and the original research into these classes of issues several years ago.

Severity

CVSS Score: 7.3 / 10 (High)
Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

runc container escape via "masked path" abuse due to mount race conditions

CVE-2025-31133 / GHSA-9493-h29p-rfm2 / GO-2025-4096

More information

Details

Impact

The OCI runtime specification has a maskedPaths feature that allows for files or directories to be "masked" by placing a mount on top of them to conceal their contents. This is primarily intended to protect against privileged users in non-user-namespaced from being able to write to files or access directories that would either provide sensitive information about the host to containers or allow containers to perform destructive or other privileged operations on the host (examples include /proc/kcore, /proc/timer_list, /proc/acpi, and /proc/keys).

maskedPaths can be used to either mask a directory or a file -- directories are masked using a new read-only tmpfs instance that is mounted on top of the masked path, while files are masked by bind-mounting the container's /dev/null on top of the masked path.

In all known versions of runc, when using the container's /dev/null to mask files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode. While /dev/null is usually created by runc when doing container creation, it is possible for an attacker to create a /dev/null or modify the /dev/null inode created by runc through race conditions with other containers sharing 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 could lead to two separate issues:

Attack 1: Arbitrary Mount Gadget (leading to Host Information Disclosure, Host Denial of Service, or Container Escape)

By replacing /dev/null with a symlink to an attacker-controlled path, an attacker could cause runc to bind-mount an arbitrary source path to a path inside the container. This could lead to:

Host Denial of Service: By bind-mounting files such as /proc/sysrq-trigger, the attacker can gain access to a read-write version of files which can be destructive to write to (/proc/sysrq-trigger would allow an attacker to trigger a kernel panic, shutting down the machine, or causing the machine to freeze without rebooting).
Container Escape: By bind-mounting /proc/sys/kernel/core_pattern, the attacker can reconfigure a coredump helper -- as kernel upcalls are not namespaced, the configured binary (which could be a container binary or a host binary with a malicious command-line) will run with full privileges on the host system. Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.

Note that while config.json allows users to bind-mount arbitrary paths (and thus an attacker that can modify config.json arbitrarily could gain the same access as this exploit), because maskedPaths is applied by almost all higher-level container runtimes (and thus provides a guaranteed mount source) this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.

Attack 2: Bypassing `maskedPaths`

While investigating Attack 1, runc discovered that the runc validation mechanism when bind-mounting /dev/null for maskedPaths would ignore ENOENT errors -- meaning that if an attacker deleted /dev/null before runc did the bind-mount, runc would silently skip applying maskedPaths for the container. (The original purpose of this ENOENT-ignore behaviour was to permit configurations where maskedPaths references non-existent files, but runc did not consider that the source path could also not exist in this kind of race-attack scenario.)

With maskedPaths rendered inoperative, an attacker would be able to access sensitive host information from files in /proc that would usually be masked (such as /proc/kcore). However, note that /proc/sys and /proc/sysrq-trigger are mounted read-only rather than being masked with files, so this attack variant will not allow the same breakout or host denial of service attacks as in Attack 1.

Patches

This advisory is being published as part of a set of three advisories:

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:

db19bbed5348 ("internal/sys: add VerifyInode helper")
8476df83b534 ("libct: add/use isDevNull, verifyDevNull")
1a30a8f3d921 ("libct: maskPaths: only ignore ENOENT on mount dest")
5d7b24240724 ("libct: maskPaths: don't rely on ENOTDIR for mount")

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. https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md

Mitigations

Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the procfs files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.

runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONE_NEWUSER) inside containers regardless of whether the container itself uses user namespaces.

Rootless containers can provide even more protection if your configuration can use them -- 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 non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling noNewPrivileges to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use ping in your containers, there is a net.ipv4.ping_group_range sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries.
Do not run untrusted container images from unknown or unverified sources.
Depending on the configuration of maskedPaths, an AppArmor profile (such as the default one applied by higher level runtimes including Docker and Podman) can block write attempts to most of /proc and /sys. This means that even with a procfs file maliciously bind-mounted to a maskedPaths target, all of the targets of maskedPaths in the default configuration of runtimes such as Docker or Podman will still not permit write access to said files. However, if a container is configured with a maskedPaths that is not protected by AppArmor then the same attack can be carried out. Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881.
Based on runc's analysis, SELinux policies have a limited effect when trying to protect against this attack. The reason is that the /dev/null bind-mount gets implicitly relabelled with context=... set to the container's SELinux context, and thus the container process will have access to the source of the bind-mount even if they otherwise wouldn't.
GHSA-cgrx-mc8f-2prm

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 coordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but their security stance is (understandably) that non-user-namespaced containers are fundamentally insecure by design.
https://linuxcontainers.org/lxc/security/

Credits

Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector (Attack 2) based on @ssst0n3's initial findings.

Severity

CVSS Score: 7.3 / 10 (High)
Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects

CVE-2025-52881 / GHSA-cgrx-mc8f-2prm / GO-2025-4098

More information

Details

Impact

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:

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:

db19bbed5348 ("internal/sys: add VerifyInode helper")
6fc191449109 ("internal: move utils.MkdirAllInRoot to internal/pathrs")
ff94f9991bd3 ("*: switch to safer securejoin.Reopen")
44a0fcf685db ("go.mod: update to github.com/cyphar/[email protected]")
77889b56db93 ("internal: add wrappers for securejoin.Proc*")
fdcc9d3cad2f ("apparmor: use safe procfs API for labels")
ff6fe1324663 ("utils: use safe procfs for /proc/self/fd loop code")
b3dd1bc562ed ("utils: remove unneeded EnsureProcHandle")
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.
  
  See https://github.com/opencontainers/selinux/pull/237 for the upstream patch.
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.

Severity

CVSS Score: 7.3 / 10 (High)
Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Container escape with malicious config due to /dev/console mount and related races in github.com/opencontainers/runc

CVE-2025-52565 / GHSA-qw9x-cqr3-wc7r / GO-2025-4097

More information

Details

Container escape with malicious config due to /dev/console mount and related races in github.com/opencontainers/runc

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Release Notes

opencontainers/runc (github.com/opencontainers/runc)

`v1.2.8`: runc v1.2.8 -- "鳥籠の中に囚われた屈辱を"

Compare Source

[!NOTE]
Some vendors were given a pre-release version of this release.
This public release includes two extra patches to fix regressions
discovered very late during the embargo period and were thus not
included in the pre-release versions. Please update to this version.

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 /proc files.

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/null
inode on top of the file. However, if an attacker can replace /dev/null
with 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/console
bind-mounts. When creating the /dev/console bind-mount (to /dev/pts/$n),
if an attacker replaces /dev/pts/$n with a symlink then runc will
bind-mount the symlink target over /dev/console. This issue affected all
versions 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.

Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

libseccomp

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:

Aleksa Sarai [email protected]
Kir Kolyshkin [email protected]
Lei Wang <ssst0n3@gmail.com>
Li Fubang [email protected]
Rodrigo Campos [email protected]
Tõnis Tiigi [email protected]

Signed-off-by: Aleksa Sarai [email protected]

`v1.2.7`

Compare Source

A wizard is never late, nor is he early, he arrives precisely when he means
to.

As runc follows Semantic Versioning, we will endeavour to not make any
breaking changes without bumping the major version number of runc.
However, it should be noted that Go API usage of runc's internal
implementation (libcontainer) is not covered by this policy.

Removed

Removed libcontainer/configs.Device* identifiers (deprecated since rc94,
use libcontainer/devices). (#2999)
Removed libcontainer/system.RunningInUserNS function (deprecated since
rc94, use libcontainer/userns). (#2999)

Deprecated

The usage of relative paths for mountpoints will now produce a warning
(such configurations are outside of the spec, and in future runc will
produce an error when given such configurations). (#2917, #3004)

Fixed

cgroupv2: devices: rework the filter generation to produce consistent
results with cgroupv1, and always clobber any existing eBPF
program(s) to fix runc update and avoid leaking eBPF programs
(resulting in errors when managing containers). (#2951)
cgroupv2: correctly convert "number of IOs" statistics in a
cgroupv1-compatible way. (#2965, #2967, #2968, #2964)
cgroupv2: support larger than 32-bit IO statistics on 32-bit architectures.
cgroupv2: wait for freeze to finish before returning from the freezing
code, optimize the method for checking whether a cgroup is frozen. (#2955)
cgroups/systemd: fixed "retry on dbus disconnect" logic introduced in rc94
cgroups/systemd: fixed returning "unit already exists" error from a systemd
cgroup manager (regression in rc94). (#2997, #2996)

Added

cgroupv2: support SkipDevices with systemd driver. (#2958, #3019)
cgroup1: blkio: support BFQ weights. (#3010)
cgroupv2: set per-device io weights if BFQ IO scheduler is available.
(#3022)

Changed

cgroup/systemd: return, not ignore, stop unit error from Destroy. ([#2946](https://redirect.github.com/opencontai

Configuration

📅 Schedule: Branch creation - "" (UTC), 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.

If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

…curity] Signed-off-by: cilium-renovate[bot] <134692979+cilium-renovate[bot]@users.noreply.github.com>

cilium-renovate · 2025-11-06T08:11:01Z

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: undefined

Command failed: make protogen
go: downloading google.golang.org/protobuf v1.36.6
go: downloading sigs.k8s.io/yaml v1.4.0
go: downloading google.golang.org/grpc v1.71.1
go: downloading github.com/sirupsen/logrus v1.9.3
go: downloading github.com/stretchr/testify v1.10.0
go: downloading golang.org/x/sys v0.32.0
go: downloading github.com/google/go-cmp v0.7.0
go: downloading github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go: downloading github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2
go: downloading gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c
go: downloading golang.org/x/net v0.38.0
go: downloading google.golang.org/genproto/googleapis/rpc v0.0.0-20250407143221-ac9807e6c755
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading github.com/kr/pretty v0.2.1
go: downloading github.com/golang/protobuf v1.5.4
go: downloading go.opentelemetry.io/otel v1.34.0
go: downloading go.opentelemetry.io/otel/sdk/metric v1.34.0
go: downloading go.opentelemetry.io/otel/sdk v1.34.0
go: downloading github.com/kr/text v0.1.0
go: downloading go.opentelemetry.io/otel/metric v1.34.0
go: downloading go.opentelemetry.io/otel/trace v1.34.0
go: downloading golang.org/x/text v0.23.0
go: downloading github.com/go-logr/logr v1.4.2
go: downloading github.com/go-logr/stdr v1.2.2
go: downloading go.opentelemetry.io/auto/sdk v1.1.0
go: downloading github.com/google/uuid v1.6.0
Unable to find image 'quay.io/cilium/cilium-builder:cd04ac813fb4763f840911c88beae99efc4aa457' locally
cd04ac813fb4763f840911c88beae99efc4aa457: Pulling from cilium/cilium-builder
59103914d20e: Pulling fs layer
17d3e8f3d0bc: Pulling fs layer
41f150d063fd: Pulling fs layer
93c374f336b7: Pulling fs layer
4f4fb700ef54: Pulling fs layer
24d10d1252ef: Pulling fs layer
d7075edb03b9: Pulling fs layer
2ad3d6c432f9: Pulling fs layer
94c7ac5a7528: Pulling fs layer
a960d8d5112e: Pulling fs layer
be78cc0a6c06: Pulling fs layer
d353a3c8fe13: Pulling fs layer
3646095f617f: Pulling fs layer
be78cc0a6c06: Waiting
d353a3c8fe13: Waiting
2ad3d6c432f9: Waiting
3646095f617f: Waiting
94c7ac5a7528: Waiting
a960d8d5112e: Waiting
93c374f336b7: Waiting
4f4fb700ef54: Waiting
24d10d1252ef: Waiting
d7075edb03b9: Waiting
41f150d063fd: Verifying Checksum
41f150d063fd: Download complete
93c374f336b7: Verifying Checksum
93c374f336b7: Download complete
4f4fb700ef54: Verifying Checksum
4f4fb700ef54: Download complete
59103914d20e: Verifying Checksum
59103914d20e: Download complete
d7075edb03b9: Verifying Checksum
d7075edb03b9: Download complete
2ad3d6c432f9: Download complete
94c7ac5a7528: Verifying Checksum
94c7ac5a7528: Download complete
59103914d20e: Pull complete
a960d8d5112e: Verifying Checksum
a960d8d5112e: Download complete
24d10d1252ef: Verifying Checksum
24d10d1252ef: Download complete
d353a3c8fe13: Verifying Checksum
d353a3c8fe13: Download complete
3646095f617f: Verifying Checksum
3646095f617f: Download complete
17d3e8f3d0bc: Verifying Checksum
17d3e8f3d0bc: Download complete
be78cc0a6c06: Verifying Checksum
be78cc0a6c06: Download complete
17d3e8f3d0bc: Pull complete
41f150d063fd: Pull complete
93c374f336b7: Pull complete
4f4fb700ef54: Pull complete
24d10d1252ef: Pull complete
d7075edb03b9: Pull complete
2ad3d6c432f9: Pull complete
94c7ac5a7528: Pull complete
a960d8d5112e: Pull complete
be78cc0a6c06: Pull complete
d353a3c8fe13: Pull complete
3646095f617f: Pull complete
Digest: sha256:2e6761058af195ed75d52187fb15e80aefdefda47f91020b597349c1e251fca4
Status: Downloaded newer image for quay.io/cilium/cilium-builder:cd04ac813fb4763f840911c88beae99efc4aa457
make: *** [Makefile:30: __check-breaking_local] Error 100
make[1]: *** [Makefile:34: all] Error 2
make: *** [Makefile:384: protogen] Error 2

fix(deps): update module github.com/opencontainers/runc to v1.2.8 [se…

3015218

…curity] Signed-off-by: cilium-renovate[bot] <134692979+cilium-renovate[bot]@users.noreply.github.com>

cilium-renovate bot requested a review from a team as a code owner November 6, 2025 08:10

cilium-renovate bot added release-blocker This PR or issue is blocking the next release. release-note/dependency This PR updates one or multiple dependencies labels Nov 6, 2025

cilium-renovate bot requested review from tixxdz and removed request for a team November 6, 2025 08:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(deps): update module github.com/opencontainers/runc to v1.2.8 [security] (v1.4) #4298

fix(deps): update module github.com/opencontainers/runc to v1.2.8 [security] (v1.4) #4298

Uh oh!

cilium-renovate bot commented Nov 6, 2025 •

edited

Loading

Uh oh!

cilium-renovate bot commented Nov 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

fix(deps): update module github.com/opencontainers/runc to v1.2.8 [security] (v1.4) #4298

Are you sure you want to change the base?

fix(deps): update module github.com/opencontainers/runc to v1.2.8 [security] (v1.4) #4298

Uh oh!

Conversation

cilium-renovate bot commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Container escape and DDoS due to arbitrary write gadgets and procfs write redirects in github.com/opencontainers/runc

Details

Severity

References

Container escape via "masked path" abuse due to mount race conditions in github.com/opencontainers/runc

Details

Severity

References

runc container escape with malicious config due to /dev/console mount and related races

Details

Impact

Additional Findings

Issue 1: Problematic Usage of os.Create

Issue 2: Malicious /dev/pts/$n Inode Attacks (TIOCGPTPEER)

Patches

Mitigations

Other Runtimes

Credits

Severity

References

runc container escape via "masked path" abuse due to mount race conditions

Details

Impact

Attack 1: Arbitrary Mount Gadget (leading to Host Information Disclosure, Host Denial of Service, or Container Escape)

Attack 2: Bypassing maskedPaths

Patches

Mitigations

Other Runtimes

Credits

Severity

References

runc container escape and denial of service due to arbitrary write gadgets and procfs write redirects

Details

Impact

Additional Impacts

Patches

Mitigations

Other Runtimes

Credits

Severity

References

Container escape with malicious config due to /dev/console mount and related races in github.com/opencontainers/runc

Details

Severity

References

Release Notes

v1.2.8: runc v1.2.8 -- "鳥籠の中に囚われた屈辱を"

Security

Static Linking Notices

v1.2.7

Removed

Deprecated

Fixed

Added

Changed

Configuration

Uh oh!

cilium-renovate bot commented Nov 6, 2025

⚠️ Artifact update problem

File name: undefined

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

cilium-renovate bot commented Nov 6, 2025 •

edited

Loading

Issue 1: Problematic Usage of `os.Create`

Issue 2: Malicious `/dev/pts/$n` Inode Attacks (`TIOCGPTPEER`)

Attack 2: Bypassing `maskedPaths`

`v1.2.8`: runc v1.2.8 -- "鳥籠の中に囚われた屈辱を"

`v1.2.7`