cgroup v2: unsafe cgroupfs mount when cgroup namespace is disabled

[xujihui1985]

Description

In a cgroup v2 environment, runc currently allows mounting cgroupfs inside a container even when the container is not running with a private cgroup namespace (cgroupns disabled).

This can lead to unintended side effects, as global mount options (e.g., nsdelegate) on the host’s cgroup filesystem may be modified or overridden by the container’s mount operation.

Problem

When cgroupns is not enabled, the container shares the host’s cgroup namespace. In this scenario:
• Mounting cgroupfs inside the container directly operates on the host’s cgroup hierarchy
• Mount options applied during the mount (e.g., nsdelegate) may:
• Override existing global mount options
• Introduce inconsistent behavior across the system
• Break assumptions about cgroup isolation

This effectively allows a container to mutate global kernel state without proper isolation, which is unsafe and unexpected.

Expected Behavior

runc should ensure safe behavior when handling cgroupfs mounts under cgroup v2. Specifically, when:
• The system is using cgroup v2, and
• The container does not have a private cgroup namespace (cgroupns disabled)

Then one of the following should be enforced:
1. Reject the mount entirely, or
2. Ensure the mount options are consistent with the host’s existing cgroupfs mount (i.e., do not override global mount options)

Proposed Solution

Adopt one of the following strategies when mounting cgroupfs under cgroup v2:

Option 1: Strict validation (preferred for safety)
• Add a validation check in runc
• If cgroupns is disabled:
• Disallow mounting cgroupfs inside the container
• Return a clear error message indicating that cgroup namespace isolation is required

Option 2: Inherit host mount configuration
• Ensure that any cgroupfs mount inside the container:
• Reuses the host’s existing mount options
• Does not override global flags such as nsdelegate

Related Work

A similar issue has been identified and addressed in LXCFS:
• Linux Containers (LXC) project PR: lxc/lxcfs#703

Impact

• Prevents containers from modifying global cgroup mount behavior
• Improves isolation guarantees under cgroup v2

[xujihui1985]

@lifubang hello, would you like to take a look at this issue?

[lifubang]

@lifubang hello, would you like to take a look at this issue?

Sorry for the delay, I’ve been quite busy these days.

I believe cgroupns is enabled by default in most modern container runtimes nowadays. However, the issue can still be reproduced by explicitly running a container with docker run --cgroupns=host.

For backward compatibility, I think Option 2 (inheriting the host’s cgroup mount configuration) is the more appropriate approach. That said, we should clearly warn users when a cgroup filesystem is mounted inside the container that it inherits the host’s mount options, so they’re aware of the potential system-wide implications.

[xujihui1985]

@lifubang hello, would you like to take a look at this issue?

Sorry for the delay, I’ve been quite busy these days.

I believe cgroupns is enabled by default in most modern container runtimes nowadays. However, the issue can still be reproduced by explicitly running a container with docker run --cgroupns=host.

For backward compatibility, I think Option 2 (inheriting the host’s cgroup mount configuration) is the more appropriate approach. That said, we should clearly warn users when a cgroup filesystem is mounted inside the container that it inherits the host’s mount options, so they’re aware of the potential system-wide implications.

Thanks for the reply, yes I agree, I will go with option 2

[cyphar]

@lifubang FWIW, I reported this a few years ago but IIRC @AkihiroSuda felt it wasn't an issue and didn't want us to re-add cgroupv1-style hacks. FWIW, I still think we should mount a subtree if cgroupns is not enabled. :/

[xujihui1985]

@lifubang FWIW, I reported this a few years ago but IIRC @AkihiroSuda felt it wasn't an issue and didn't want us to re-add cgroupv1-style hacks. FWIW, I still think we should mount a subtree if cgroupns is not enabled. :/

@cyphar The issue is that if cgroupns are not enabled on a host using cgroup v2 (although this is not recommended, it is still allowed), operations inside a container may directly affect the host’s cgroup filesystem. This can lead to unintended modifications of the host cgroup hierarchy, which is undesirable. BTW the link you reference is broken.

[lifubang]

I still think we should mount a subtree if cgroupns is not enabled. :/

In fact, I agree with your point -- but perhaps we can defer implementing this until we have clearer results or requirements.

At the very least, we shouldn’t override the host’s cgroup mount options when cgroup namespaces aren’t in use.
(Yes, mounting a subtree also resolves the issue -- but we still need more discussion.)

BTW the link you reference is broken.

This is an undisclosed security issue.

[xujihui1985]

mounting a subtree

may I know how does mounting a subtree work?

[lifubang]

mounting a subtree

may I know how does mounting a subtree work?

Via a bind mount, please see: https://github.com/opencontainers/runc/blob/main/libcontainer/rootfs_linux.go#L399-L414