[1.2.8] runc appears to apply rlimits to itself prior to validating device nodes

[samuelkarp]

Description

As a fix to CVE-2025-31133 and CVE-2025-52565, runc applies more validation to the device nodes that are specified in the OCI config and attempts to detect that they are “safe”. On systems with very large numbers of devices, runc now fails to correctly run when a low RLIMIT_NOFILE is present in the config. For example:

$ sudo ctr run --rm --tty --privileged docker.io/library/busybox:latest broken
ctr: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error creating device nodes: mkdir parent of device inode "/dev/ng3n1": re-opening handle to "/run/containerd/io.containerd.runtime.v2.task/default/broken/rootfs/dev": get safe /proc/thread-self/fd handle: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: too many open files

ctr specifies RLIMIT_NOFILE as 1024:1024 by default. The system in question has ~700 devices present in /dev, and the --privileged flag causes ctr to pass all of them through to runc in the bundle.

I have patched ctr to allow specifying a higher RLIMIT_NOFILE, which allows the container to be created as normal:

$ sudo ./ctr run --rm --tty --rlimit-nofile 1048576:1048576 --privileged docker.io/library/busybox:latest fixed
/ #

It seems to me that runc should apply rlimits specified in the bundle after the logic to validate device nodes.

Steps to reproduce the issue

1. Obtain a system with a very large number of devices in /dev
2. sudo ctr run --rm --tty --privileged docker.io/library/busybox:latest broken
3. runc create failed: unable to start container process: error during container init: error creating device nodes: mkdir parent of device inode "/dev/ng3n1": re-opening handle to "/run/containerd/io.containerd.runtime.v2.task/default/broken/rootfs/dev": get safe /proc/thread-self/fd handle: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: too many open files

Describe the results you received and expected

Received:

runc create failed: unable to start container process: error during container init: error creating device nodes: mkdir parent of device inode "/dev/ng3n1": re-opening handle to "/run/containerd/io.containerd.runtime.v2.task/default/broken/rootfs/dev": get safe /proc/thread-self/fd handle: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: too many open files

Expected: container runs normally

What version of runc are you using?

$ runc --version
runc version 1.2.7
commit: 3efe6c352f3f0b037249928ad9525b9194bc204f
spec: 1.2.0
go: go1.23.12
libseccomp: 2.6.0

(This version has the CVE patches applied that were sent to distributors)

Host OS information

$ cat /etc/os-release
NAME="Container-Optimized OS"
ID=cos
PRETTY_NAME="Container-Optimized OS from Google"
HOME_URL="https://cloud.google.com/container-optimized-os/docs"
BUG_REPORT_URL="https://cloud.google.com/container-optimized-os/docs/resources/support-policy#contact_us"
GOOGLE_METRICS_PRODUCT_ID=26
KERNEL_COMMIT_ID=13ec0b222243e837d814745f08d4dc0a950c2cae
GOOGLE_CRASH_ID=Lakitu
VERSION=125
VERSION_ID=125
BUILD_ID=19216.104.17

Host kernel information

$ uname -a
Linux gke-test 6.12.55+ #1 SMP Tue Nov 11 08:47:57 UTC 2025 x86_64 INTEL(R) XEON(R) PLATINUM 8581C CPU @ 2.10GHz GenuineIntel GNU/Linux

[cyphar]

I think this is more indicative of a fd leak than an issue with where we set rlimits -- I would not expect us to have more than 1000 file descriptors open at a single time, even with the validation logic we have...

[cyphar]

Ah, #5022 was already opened.