[v1.3.3] Error response from daemon: failed to create task for container

[zkolpet]

Description

Hello,

We are using Ubuntu 22.04 in our environment. One docker container using ".." in its bind mount paths stopped starting with this new runc v1.3.3 version. Full error being thrown is:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented: unknown

The additional info I received is:
This issue is related to a regression introduced in the Ubuntu runc package version [1.3.3-0ubuntu1~22.04.2]
The problem originates from an Ubuntu-specific patch (openat2-improve-resilience-on-busy-systems.patch) that breaks container startup on some systems or kernel versions.

Steps to reproduce the issue

1. On Ubuntu 22.04 machine install runc version: 1.3.3-0ubuntu1~22.04.2
2. Try to start any docker container using ".." in its bind mount paths
3. Error is thrown

Describe the results you received and expected

Received:
Docker container does not start. This error is thrown:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented: unknown

Expected:
Docker container is successfully started

What version of runc are you using?

user@host ~$ runc --version runc version 1.3.3-0ubuntu1~22.04.2 spec: 1.2.1 go: go1.23.1 libseccomp: 2.5.3 user@host ~$

Host OS information

user@host ~$ cat /etc/os-release
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
user@host ~$

Host kernel information

user@host ~$ uname -a
Linux host 5.15.0-161-generic #171-Ubuntu SMP Sat Oct 11 08:17:01 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
user@host ~$

[cyphar]

The problem originates from an Ubuntu-specific patch (openat2-improve-resilience-on-busy-systems.patch) that breaks container startup on some systems or kernel versions.

This patch isn't Ubuntu-specific -- the patch is upstream in a41366e, and I also don't think this is the cause of the error (that patch just increased the retry amount when using openat2 but the error is coming from code added in an earlier patch -- ff6fe13).

error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented: unknown

🤔... This really doesn't make sense. This error (ENOSYS) is returned when a system call is not supported by the running kernel. However:

• pathrs-lite checks for whether openat2 is supported and has a different fallback for older kernels. This code is very extensively tested on Ubuntu 22.04 in github.com/cyphar/filepath-securejoin's CI.
• openat2 was added to Linux in 5.6, and the kernel for Ubuntu 22.04 (as your own bug report states) is 5.15. So I'm incredibly confused where this error would come from...

I'll need to try to reproduce this in a VM (I can't reproduce it on my machine). Can you give me an example docker run command-line (using a public image if necessary) that fails with the error you've provided?

[zkolpet]

Unfortunately I don't have any public docker image example. This failure is happening within our proprietary docker image which I can't share.

Is there any other way to troubleshoot this?

[cyphar]

I guessed as much, can you try to create a minimal example using a public docker image? If the issue is just a bind-mount with .. then I would expect

% docker run -it -v /tmp:/usr/../tmp2 alpine sh

to fail with the error you described, but it doesn't on my machine.

[lifubang]

Might this be caused by seccomp filters? We call HasOpenat2 just once.

[zkolpet]

@cyphar
I was able to also start this alpine docker container in the same environment in which the other (our) docker container is failing to start with above mentioned error.

Is there anything specific which I could check/verify on our side? Some configuration/logs/anything?

[zkolpet]

@cyphar

I can see identical issue being discussed here for zenika/alpine-chrome:

jlandure/alpine-chrome#272

Might be helpful.

[cyphar]

Ah wait, CloseExecFrom is called after we apply seccomp (and presumably you are using a custom profile which doesn't permit openat2) -- I think you might be right @lifubang...

In that case we need to do a fallback even if openat2 was supported when we first attempted it. (Or we can just remove the caching in linux.HasOpenat2, though we could cache as soon as we hit a failure...)

EDIT: Another choice would be to see if the value of Seccomp_filters in /proc/thread-self/status has changed, but this will require more syscalls than we would save just testing openat2 each time. We can also not bother pre-checking openat2 but I'm a little worried about possible "downgrade attacks" this would open us up to.

[shismaha-te]

@cyphar We are also seeing this exact error in our environments (ubuntu:22.04) with newer versions of runc (1.4.0). Older version of runc (1.1.14) is working fine.

If I add (allow) the following system calls in my seccomp profile:

• fsopen
• fsconfig
• fspick
• openat2
• open_tree
• move_mount
• mount_setattr

I am able to get past the error (with newer runc 1.4.0). However, with both newer and older runc, when I allow these syscalls, my containers are getting restarted frequently. In the docker logs, I see these delete task events.

level=info msg="ignoring event" container=<id> module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
level=info msg="ignoring event" container=<id> module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
level=info msg="ignoring event" container=<id> module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"

[shismaha-te]

@cyphar The restarting of containers was a red herring, mostly a config issue/setup in our environment.

For the error reported:

error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented: unknown

We were able to add the above system calls to our seccomp profile and that seems to work with runc-1.3.3

[lifubang]

Hi @zkolpet @shismaha-te,

Could you please share the config.json file for the failing container? You can retrieve it by following these steps:

# 1. Get the container ID
root@acmcoder:/home/lifubang# docker ps
CONTAINER ID   IMAGE     COMMAND       CREATED      STATUS       PORTS     NAMES
02066602b313   ubuntu    "/bin/bash"   9 days ago   Up 2 hours             unruffled_dirac

# 2. Check if config.json exists — you can use the truncated ID from `docker ps` and press Tab to auto-complete the full path:
root@acmcoder:/home/lifubang# ls /run/containerd/io.containerd.runtime.v2.task/moby/02066602b3138942a2ec0fd7702e49bcfd7494d5683dfd9bcfd7dd94114d2772/config.json
/run/containerd/io.containerd.runtime.v2.task/moby/02066602b3138942a2ec0fd7702e49bcfd7494d5683dfd9bcfd7dd94114d2772/config.json

# 3. Output the contents of config.json
root@acmcoder:/home/lifubang# cat /run/containerd/io.containerd.runtime.v2.task/moby/02066602b3138942a2ec0fd7702e49bcfd7494d5683dfd9bcfd7dd94114d2772/config.json

[cyphar]

@lifubang I already know what the issue is -- see #5007 (comment), I'm working on a patch.

Though, the same issue should not be present for syscalls other than openat2(2) (i.e., it should not be necessary to permit other syscalls) -- we have a fallback to open("/proc") for any errors when trying to use the new mount API:

func getProcRoot(subset bool) (*Handle, error) {
	proc, err := privateProcRoot(subset)
	if err != nil {
		// Fall back to using a /proc handle if making a private mount failed.
		// If we have openat2, at least we can avoid some kinds of over-mount
		// attacks, but without openat2 there's not much we can do.
		proc, err = unsafeHostProcRoot()
	}
	return proc, err
}

(This is different to openat2, which only relies on the cached information and thus causes issues.)

Also, we use a cached procfs for /proc/thread-self so seccomp being applied doesn't matter with the current implementation. I tested #5015 with openat2 enabled and it works.

[lifubang]

Though, the same issue should not be present for syscalls other than openat2(2) (i.e., it should not be necessary to permit other syscalls)

Yes — because we’ve cached the file descriptor returned by fsmount, we don’t need to call fsmount or fsopen again after applying the seccomp filters. Therefore, there’s no need to allow the new mount API in the seccomp policy.