On Wednesday, 5 November 2025 at 10:58, Aleksa Sarai <[email protected]> wrote:

> 

> 

> | NOTE: This advisory was sent to [email protected]
> 

> | on 2025-10-16. If you ship any Open Container Initiative software, we
> | highly recommend that you subscribe to our security-announce list in
> | order to receive more timely disclosures of future security issues.
> | The procedure for subscribing to security-announce is outlined here:
> | 
> https://github.com/opencontainers/.github/blob/main/SECURITY.md#disclosure-distribution-list
> 

> 

> Hello,
> 

> This is a notification to vendors that use or ship runc about THREE (3)
> high-severity vulnerabilities (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.
> 

> Today we have released the following runc releases which include more
> than 20 patches to resolve this issue:
> 

> * runc v1.4.0-rc.3 
> https://github.com/opencontainers/runc/releases/tag/v1.4.0-rc.3
> 

> * runc v1.3.3 https://github.com/opencontainers/runc/releases/tag/v1.3.3
> 

> * runc v1.2.8 https://github.com/opencontainers/runc/releases/tag/v1.2.8
> 

> 

> We strongly recommend you update as soon as possible. For your own
> reference I have attached a tarball of the patches (which apply cleanly
> on top of runc v1.2.7, v1.3.2 and v1.4.0-rc.2).
> 

> Unfortunately the patches are are quite large as they required a lot of
> development work in github.com/cyphar/filepath-securejoin along with
> quite deep changes to runc. I would recommend just going with the
> released versions.
> 

> Note that these patches have not been split into per-CVE patches, as the
> resolutions for each issue overlap and so some patches help resolve more
> than one CVE on the list. We strongly recommend simply applying all of
> the provided patches (we have included a squashed single-patch version
> for your convenience -- see v1.[234].patch).
> 

> | NOTE:
> | Some vendors were given a pre-release version of this release.
> | These public releases include 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.
> | The above tarball includes these extra patches as well.
> 

> /*** Vulnerabilities **/
> 

> Below is a break-down of the key points of each issue. Once this
> vulnerability is made public on the embargo date, the linked advisory
> pages will contain some more information about the issues.
> 

> Please note that while these issues are generally related, the available
> mitigations (if any) vary from issue to issue. However, all of these
> attacks rely on starting containers with custom mount configurations --
> if you do not run untrusted container images from unknown or unverified
> sources then these attacks would not be possible to exploit. Note that
> Dockerfiles support custom mount configurations (with RUN --mount=...)
> and so these issues are also exploitable from Dockerfiles.
> 

> Also please note that the below CVSS scores are based on the threat
> model from runc's point of view. If you were to analyse the same
> vulnerability from the perspective of network-enabled systems like
> Docker or Kubernetes you would likely end up with a much higher
> severity.
> 

> / CVE-2025-31133 */
> 

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

> 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 (7.3)
> 

> https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2
> 

> 

> 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 affects all known
> runc versions.

Syd, and therefore syd-oci, preopens a fd to /dev/null at startup and
exits with error in case it's not the expected character device. Open
is done with openat2 without resolving symlinks. Does this mean syd-oci
is not affected? Is there some POC I can test with? TYVMIA.
 

> 

> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> https://www.cyphar.com/

Best regards,
Ali Polatel

Attachment: publickey - [email protected] - 0xC22DA9DE.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to