CVE-2022-31030

containerd is an open source container runtime. A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used.

containerd is an open source container runtime. A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used.

Impact

A bug was found in containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility.

Patches

This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images and commands are used.

References

• Similar fix in cri-o's CRI implementation https://github.com/cri-o/cri-o/security/advisories/GHSA-fcm2-6c3h-pg6j

Credits

The containerd project would like to thank David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the containerd security policy during a security audit sponsored by CNCF and facilitated by OSTIF.

For more information

If you have any questions or comments about this advisory:

• Open an issue in containerd
• Email us at [email protected]

containerd is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

Security Fix(es):

containerd is an open source container runtime. A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used.(CVE-2022-31030)

containerd is an open source container runtime. A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the ExecSync API. This can cause containerd to consume all available memory on the computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to use containerd's CRI implementation; ExecSync may be used when running probes or when executing processes via an "exec" facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used.

containerd CRI plugin: Host memory exhaustion through ExecSync in github.com/containerd/containerd

A bug was found in the containerd's CRI implementation where programs inside a container can cause the containerd daemon to consume memory without bound during invocation of the 'ExecSync' API. (CVE-2022-31030)

These are all security issues fixed in the containerd-1.6.6-1.1 package on the GA media of openSUSE Tumbleweed.

This update for containerd fixes the following issues:

containerd:

• CVE-2022-31030: Fixed denial of service via invocation of the ExecSync API (bsc#1200145)

docker:

• Update to Docker 20.10.17-ce. See upstream changelog online at https://docs.docker.com/engine/release-notes/#201017 . bsc#1200145

runc:

Update to runc v1.1.3.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.3.

• Our seccomp -ENOSYS stub now correctly handles multiplexed syscalls on s390 and s390x. This solves the issue where syscalls the host kernel did not support would return -EPERM despite the existence of the -ENOSYS stub code (this was due to how s390x does syscall multiplexing).
• Retry on dbus disconnect logic in libcontainer/cgroups/systemd now works as intended; this fix does not affect runc binary itself but is important for libcontainer users such as Kubernetes.
• Inability to compile with recent clang due to an issue with duplicate constants in libseccomp-golang.
• When using systemd cgroup driver, skip adding device paths that don't exist, to stop systemd from emitting warnings about those paths.
• Socket activation was failing when more than 3 sockets were used.
• Various CI fixes.
• Allow to bind mount /proc/sys/kernel/ns_last_pid to inside container.

• Fix issues with newer syscalls (namely faccessat2) on older kernels on s390(x) caused by that platform's syscall multiplexing semantics. (bsc#1192051 bsc#1199565)

Update to runc v1.1.2.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.2.

Security issue fixed:

• CVE-2022-29162: A bug was found in runc where runc exec --cap executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment. (bsc#1199460)

• runc spec no longer sets any inheritable capabilities in the created example OCI spec (config.json) file.

Update to runc v1.1.1.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.1.

• runc run/start can now run a container with read-only /dev in OCI spec, rather than error out. (#3355)
• runc exec now ensures that --cgroup argument is a sub-cgroup. (#3403) libcontainer systemd v2 manager no longer errors out if one of the files listed in /sys/kernel/cgroup/delegate do not exist in container's cgroup. (#3387, #3404)
• Loosen OCI spec validation to avoid bogus 'Intel RDT is not supported' error. (#3406)
• libcontainer/cgroups no longer panics in cgroup v1 managers if stat of /sys/fs/cgroup/unified returns an error other than ENOENT. (#3435)

Update to runc v1.1.0.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.0.

• libcontainer will now refuse to build without the nsenter package being correctly compiled (specifically this requires CGO to be enabled). This should avoid folks accidentally creating broken runc binaries (and incorrectly importing our internal libraries into their projects). (#3331)

Update to runc v1.1.0~rc1.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.0-rc.1.

• Add support for RDMA cgroup added in Linux 4.11.
• runc exec now produces exit code of 255 when the exec failed. This may help in distinguishing between runc exec failures (such as invalid options, non-running container or non-existent binary etc.) and failures of the command being executed.
• runc run: new --keep option to skip removal exited containers artefacts. This might be useful to check the state (e.g. of cgroup controllers) after the container hasexited.
• seccomp: add support for SCMP_ACT_KILL_PROCESS and SCMP_ACT_KILL_THREAD (the latter is just an alias for SCMP_ACT_KILL).
• seccomp: add support for SCMP_ACT_NOTIFY (seccomp actions). This allows users to create sophisticated seccomp filters where syscalls can be efficiently emulated by privileged…

This update for containerd, docker and runc fixes the following issues:

containerd:

• CVE-2022-31030: Fixed denial of service via invocation of the ExecSync API (bsc#1200145)

docker:

• Update to Docker 20.10.17-ce. See upstream changelog online at https://docs.docker.com/engine/release-notes/#201017. (bsc#1200145)

runc:

Update to runc v1.1.3.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.3.

• Our seccomp -ENOSYS stub now correctly handles multiplexed syscalls on s390 and s390x. This solves the issue where syscalls the host kernel did not support would return -EPERM despite the existence of the -ENOSYS stub code (this was due to how s390x does syscall multiplexing).
• Retry on dbus disconnect logic in libcontainer/cgroups/systemd now works as intended; this fix does not affect runc binary itself but is important for libcontainer users such as Kubernetes.
• Inability to compile with recent clang due to an issue with duplicate constants in libseccomp-golang.
• When using systemd cgroup driver, skip adding device paths that don't exist, to stop systemd from emitting warnings about those paths.
• Socket activation was failing when more than 3 sockets were used.
• Various CI fixes.
• Allow to bind mount /proc/sys/kernel/ns_last_pid to inside container.

• Fixed issues with newer syscalls (namely faccessat2) on older kernels on s390(x) caused by that platform's syscall multiplexing semantics. (bsc#1192051 bsc#1199565)

Update to runc v1.1.2.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.2.

Security issue fixed:

• CVE-2022-29162: A bug was found in runc where runc exec --cap executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment. (bsc#1199460)

• runc spec no longer sets any inheritable capabilities in the created example OCI spec (config.json) file.

Update to runc v1.1.1.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.1.

• runc run/start can now run a container with read-only /dev in OCI spec, rather than error out. (#3355)
• runc exec now ensures that --cgroup argument is a sub-cgroup. (#3403) libcontainer systemd v2 manager no longer errors out if one of the files listed in /sys/kernel/cgroup/delegate do not exist in container's cgroup. (#3387, #3404)
• Loosen OCI spec validation to avoid bogus 'Intel RDT is not supported' error. (#3406)
• libcontainer/cgroups no longer panics in cgroup v1 managers if stat of /sys/fs/cgroup/unified returns an error other than ENOENT. (#3435)

Update to runc v1.1.0.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.0.

• libcontainer will now refuse to build without the nsenter package being correctly compiled (specifically this requires CGO to be enabled). This should avoid folks accidentally creating broken runc binaries (and incorrectly importing our internal libraries into their projects). (#3331)

Update to runc v1.1.0~rc1.

Upstream changelog is available from https://github.com/opencontainers/runc/releases/tag/v1.1.0-rc.1.

• Add support for RDMA cgroup added in Linux 4.11.

• runc exec now produces exit code of 255 when the exec failed. This may help in distinguishing between runc exec failures (such as invalid options, non-running container or non-existent binary etc.) and failures of the command being executed.

• runc run: new --keep option to skip removal exited containers artefacts. This might be useful to check the state (e.g. of cgroup controllers) after the container hasexited.
• seccomp: add support for SCMP_ACT_KILL_PROCESS and SCMP_ACT_KILL_THREAD (the latter is just an alias for SCMP_ACT_KILL).
• seccomp: add support for SCMP_ACT_NOTIFY (seccomp actions). This allows users to create sophisticated seccomp filters where syscalls can be efficiently emulated by…

It was discovered that containerd insufficiently restricted permissions on container root and plugin directories. If a user or automated system were tricked into launching a specially crafted container image, a remote attacker could traverse directory contents and modify files and execute programs on the host file system, possibly leading to privilege escalation. (CVE-2021-41103)

It was discovered that containerd incorrectly handled file permission changes. If a user or automated system were tricked into launching a specially crafted container image, a remote attacker could change permissions on files on the host file system and possibly escalate privileges. (CVE-2021-32760)

It was discovered that containerd allows attackers to gain access to read- only copies of arbitrary files and directories on the host via a specially- crafted image configuration. An attacker could possibly use this issue to obtain sensitive information. (CVE-2022-23648)

It was discovered that containerd incorrectly handled certain memory operations. A remote attacker could use this to cause a denial of service. (CVE-2022-31030)

It was discovered that containerd incorrectly handled memory when receiving certain faulty Exec or ExecSync commands. A remote attacker could possibly use this issue to cause a denial of service or crash containerd. (CVE-2022-23471, CVE-2022-31030)

It was discovered that containerd incorrectly set up inheritable file capabilities. An attacker could possibly use this issue to escalate privileges inside a container. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-24769)

It was discovered that containerd incorrectly handled access to encrypted container images when using imgcrypt library. A remote attacker could possibly use this issue to access encrypted images from other users. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-24778)