Re: runc container breakouts via procfs writes: CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881

[Ali Polatel <alip () hexsys org>]

On Wednesday, 5 November 2025 at 10:58, Aleksa Sarai <cyphar () cyphar com> wrote:

>

>

> | NOTE: This advisory was sent to security-announce () opencontainers org

> | 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 - alip@hexsys.org - 0xC22DA9DE.asc
Description:

Attachment: signature.asc
Description: OpenPGP digital signature