runc cannot mount host root as container root (`[...] is on the top of rootfs [...]`)

[akhilerm]

Description

While trying to create a kubernetes pod that mounts the host root as the container root, gives the following error.

FATA[0000] starting the container "1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b": rpc error: code = Unknown desc = failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/" to rootfs at "/": create mountpoint for / mount: mountpoint "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs" is on the top of rootfs "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs"

Steps to reproduce the issue

pod.json

{
  "metadata": {
    "name": "host-mount-pod-root",
    "namespace": "default",
    "uid": "host-mount-pod-uid",
    "attempt": 1
  },
  "log_directory": "/tmp",
  "linux": {
    "security_context": {
      "privileged": true,
      "namespace_options": {
        "network": 2
      }
    },
    "cgroup_parent": "/test.slice/sleep-pod.slice"
  }
}

container.json

{
  "metadata": {
    "name": "debug-shell"
  },
  "image": {
    "image": "ubuntu:24.04"
  },
  "command": [
    "/bin/bash",
    "-c",
    "sleep 3600"
  ],
  "mounts": [
    {
      "container_path": "/",
      "host_path": "/",
      "readonly": false
    }
  ],
  "linux": {
    "security_context": {
      "privileged": true
      }
    }
  }
}

1. Create the pod sandbox

sudo crictl -r /home/akhil/Work/dev-config.d/containerd/run/containerd/containerd.sock runp pod.json

2. create the container

sudo crictl -r /home/akhil/Work/dev-config.d/containerd/run/containerd/containerd.sock create <POD_ID from previous step> container.json pod.json

3. Start the container

sudo crictl -r /home/akhil/Work/dev-config.d/containerd/run/containerd/containerd.sock start <CONTAINER ID>
FATA[0000] starting the container "1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b": rpc error: code = Unknown desc = failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/" to rootfs at "/": create mountpoint for / mount: mountpoint "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs" is on the top of rootfs "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs"

Describe the results you received and expected

The container was not started with the following error

OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/" to rootfs at "/": create mountpoint for / mount: mountpoint "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs" is on the top of rootfs "/home/akhil/Work/dev-config.d/containerd/run/containerd/io.containerd.runtime.v2.task/k8s.io/1492434d8c56adfa15cbb2a4a861aefe559c1d4c29445961ca5152a8efafd26b/rootfs"

The regression started from d40b343 which fixed CVE-2025-52881

What version of runc are you using?

runc version 1.4.0-rc.1+dev
commit: v1.4.0-rc.1-198-gf29c4df1
spec: 1.3.0
go: go1.24.0
libseccomp: 2.5.3

containerd version
containerd github.com/containerd/containerd/v2 v2.2.0 1c4457e00facac03ce1d75f7b6777a7a851e5c41

Host OS information

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Host kernel information

Linux am021636 5.15.0-161-generic #171-Ubuntu SMP Sat Oct 11 08:17:01 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

[akhilerm]

@cyphar Will this be the expected behaviour going forward in runc or an actual regression?

[rata]

@akhilerm is there a real-world use case that does this? It feels very weird to have a container that just runs on the host's /. The binaries need to be on the host, the container image is almost irrelevant, etc.

Can you share about the use case?

I haven't checked the code to see how to handle it (it might be simple, it might be super ugly), checking that will help to get an idea. But I'd like to understand who is affected, as it feels like super weird at first sight to me.

[cyphar]

Hmm, when I did the refactor I thought that we already blocked this and was just reworking the code. Let me think about it a bit...

One issue we have is that allowing overmounts on / can lead to /proc being fake (we do have hardening against that now, so this is less of an issue than before), but you could argue that this is fine if a user configured that? Hmm...

Christian and I came up with an interesting idea for improving container mount namespace creation, switching to that plus the new mount API might make this safe to do, I'm not sure...

@rata AFAICS the issue is the mount destination is /, not that the source is /. If you aren't using user namespaces, mounting / into the container is wildly unsafe.

[akhilerm]

AFAICS the issue is the mount destination is /, not that the source is /

Yep, this is the case. We were mounting host / into container /,

Can you share about the use case?

for performing some periodic operations on the host OS. Though that was not the ideal way to make changes to host OS, we didnt notice it until the runc update broke the workflow.

switching to that plus the new mount API might make this safe to do

just curious, will that break the pivot_root if host root is used as container rootfs in this case.

Also, tried the same with crun (1.25.1) and the host / to container / mount is working.