CVE-2024-40635

containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5, and 2.2.0. A workaround is to set up an admission controller to control access to pods/attach resources.

containerd versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directories /var/lib/containerd, /run/containerd/io.containerd.grpc.v1.cri, and /run/containerd/io.containerd.sandbox.controller.v1.shim are created with incorrect permissions.

In containerd versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts CDI annotations from untrusted checkpoint image metadata during container restoration. A user with pod creation permissions can bypass standard Kubernetes resource allocation and inject arbitrary devices or host mounts into the restored container.

A vulnerability in containerd prior to versions 2.3.2, 2.2.5 and 2.1.9 allows an attacker with pod creation permissions to poison the local image cache via a crafted checkpoint image. Missing validation of image references in the checkpoint import process enables assigning an arbitrary local tag to a malicious image.

containerd prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5 has a flaw where the layer unpack handler repeatedly traverses directories for certain opaque whiteout configurations. A malicious image layer can trigger repeated directory traversals while opaque whiteouts are processed. Pulling or importing the image can consume CPU, delay container startup, and reduce image-pull concurrency for unrelated deployments.

containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are not affected. This issue is fixed in versions 2.2.7 and 2.3.4.

A vulnerability in containerd (open-source container runtime) prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1. A crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start), causing long ContainerCreating stalls and, at larger sizes, node/runtime instability.

Prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5, containerd on Linux with the CRI plugin enabled can indefinitely block the drainExecSyncIO goroutine in internal/cri/server/container_execsync.go when CRI ExecSync is used by exec probes or lifecycle hooks that launch long-lived background child processes retaining standard input and output pipes. The input and output drain phase has no default timeout and did not stop when the request context was canceled.

A vulnerability in containerd allows reading arbitrary files on the host via kubectl logs. The bug occurs in the CRI plugin, which restores container.log from a checkpoint image without validating a symlinked path.

A vulnerability in containerd allows memory exhaustion via a maliciously crafted container image, causing an OOM kill of the containerd process and making the runtime API unavailable. Affected versions are prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2.