Update module github.com/opencontainers/runc to v1.4.3 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/opencontainers/runc	v1.4.2 → v1.4.3

---

runc: 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, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on 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 ro layer that masks any malicious /dev symlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious /dev symlink 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 ptmx seems like a significant issue, in practice it is quite limited. Notably, devpts does not permit you to unlink /dev/pts/ptmx regardless of privileges and so it is not a usable target for this attack. Additionally, while /dev/ptmx can be unlinked^‡, trying to use an image with a symlink from /dev to /dev will 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 called ptmx that 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/kcore
• fd → /proc/self/fd/
• ptmx → pts/ptmx
• stdin → /proc/self/fd/0
• stdout → /proc/self/fd/1
• stderr → /proc/self/fd/2

Note that none of these symlinks are likely to point to user-controlled data -- the /proc/self/fd/$n symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the pts/ptmx symlink 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 glibc seemingly only attempts to use /dev/ptmx when creating new terminals and thus most terminal managers (including tmux) and shell tools (including sudo -- but not su) would fail to start and thus bring the system to a halt. setupPtmx does add a symlink to /dev/pts/ptmx afterwards but on some systems the mode of the host /dev/pts/ptmx is set to 0o000 which 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_t SELinux label rules (or custom AppArmor rules for the host runc context) 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

• commit opencontainers/runc@864db8042dbb ("rootfs: make /dev initialisation code fd-based")
• GHSA-7vwr-4279-7gq5

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 Score: 4.8 / 10 (Medium)
• Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N

References

• https://github.com/opencontainers/runc/security/advisories/GHSA-xjvp-4fhw-gc47
• https://github.com/advisories/GHSA-xjvp-4fhw-gc47

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

---

Release Notes

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

v1.4.3: runc 1.4.3 -- "The best way to irritate him is to feed his grandmother to the Ravenous Bugblatter Beast of Traal."

Compare Source

This is the third patch release of the 1.4.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 /dev symlink to have
  limited 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.

Fixed

• Various integration test improvements. (#​5222, #​5237, #​5226, #​5229, #​5239,
  #​5249, #​5269, #​5287, #​5295, #​5304)

Changed

• When masking directories with maskPaths, runc will now re-use a single
  tmpfs instance (which is not writable) to reduce the number tmpfs
  superblocks 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 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:

• Akihiro Suda akihiro.suda.cz@hco.ntt.co.jp
• Aleksa Sarai cyphar@cyphar.com
• Ayato Tokubi atokubi@redhat.com
• Davanum Srinivas davanum@gmail.com
• Kevin Berry <kpberry11@​gmail.com>
• Kir Kolyshkin kolyshkin@gmail.com
• Li Fubang lifubang@acmcoder.com
• Ricardo Branco rbranco@suse.de
• Rodrigo Campos Catelin rodrigo@amutable.com
• Tianon Gravi admwiggin@gmail.com

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

---

Configuration

📅 Schedule: (in timezone UTC)

• 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: Never, 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 was generated by Mend Renovate. View the repository job log.

[Luap99]

LGTM