Zombie process if runc killed by seccomp before execve

[ilp-sys]

I found that runc uses 22 system calls between installing the seccomp filter and calling execve.

This list may not be complete, but at least these system calls must be allowed for the container to start.

{
    "defaultAction": "SCMP_ACT_ALLOW",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "fcntl",
                "close",
                "chdir",
                "capget",
                "capset",
                "prctl",
                "openat",
                "newfstatat",
                "fstat",
                "epoll_ctl",
                "read",
                "write",
                "setgroups",
                "getpid",
                "tgkill",
                "futex",
                "setgid",
                "setuid",
                "getcwd",
                "getppid",
                "getdents64",
                "fstatfs"
            ],
            "action": "SCMP_ACT_KILL"
        }                                                                                                                                                                                                                                                       ]
}

If one of them is blocked with SCMP_ACT_KILL, the runc process is killed and stays as a zombie.

Examples:

1. docker run command hangs if these syscalls blocked

$ sudo docker run --security-opt seccomp=filter.seccomp.json hello-world
^C^C^C
got 3 SIGTERM/SIGINTs, forcefully exiting

2. Audit log

$ sudo grep SECCOMP /var/log/audit/audit.log
type=SECCOMP msg=audit(1759384889.819:70): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=2640 comm="runc:[2:INIT]" exe="/runc" sig=31 arch=c000003e syscall=72 compat=0 ip=0x40b40e code=0x0AUID="unset" UID="root" GID="root" ARCH=x86_64 SYSCALL=fcntl

3. docker ps -a shows the container stuck in Created:

$ sudo docker ps -a
CONTAINER ID   IMAGE         COMMAND    CREATED          STATUS    PORTS     NAMES
bc73f441bb99   hello-world   "/hello"   11 seconds ago   Created             agitated_franklin

4. docker rm -f also hangs.

$ sudo docker rm -f bc73f441bb99
^CDelete "http://%2Fvar%2Frun%2Fdocker.sock/v1.47/containers/bc73f441bb99?force=1": context canceled

runc list shows nothing, but the container still appears in Docker.

$ runc list
ID          PID         STATUS      BUNDLE      CREATED     OWNER
$ sudo docker ps -a
CONTAINER ID   IMAGE         COMMAND    CREATED         STATUS    PORTS     NAMES
bc73f441bb99   hello-world   "/hello"   2 minutes ago   Created             agitated_franklin

5.Process tree:

root        1956  0.0  0.3 1238020 12328 ?       Sl   05:48   0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id bc73f441bb99276d8d1dd4f3fab65bab046c01a0b4096cf262da55302fbb623b -address /run/containerd/containerd.sock
root        1965  0.0  0.2 1974380 11456 ?       Sl   05:48   0:00  \_ runc --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v2.task/moby/bc73f441bb99276d8d1dd4f3fab65bab046c01a0b4096cf262da55302fbb623b/log.json --log-format json --systemd-cgroup create --bundle /run/containerd/io.containerd.runtime.v2.task/moby/bc73f441bb99276d8d1dd4f3fab65bab046c01a0b4096cf262da55302fbb623b --pid-file /run/containerd/io.containerd.runtime.v2.task/moby/bc73f441bb99276d8d1dd4f3fab65bab046c01a0b4096cf262da55302fbb623b/init.pid bc73f441bb99276d8d1dd4f3fab65bab046c01a0b4096cf262da55302fbb623b
root        1976  0.0  0.0      0     0 ?        Zsl  05:48   0:00      \_ [runc:[2:INIT]] <defunct>

I am not sure whether this is an actual issue or just undefined behavior.
When containers are killed by seccomp after execve, they usually display clear error messages, but in this case they do not—it just hangs.
At the very least, the zombie process should be handled at some point.

---

versions:

$ runc --version
runc version 1.2.5-0ubuntu1~22.04.1
spec: 1.2.0
go: go1.22.2
libseccomp: 2.5.3

[ilp-sys]

I have reported this in #5087