github.com/containerd/containerd/v2: containerd CRI plugin: mount and snapshot leak when container checkpoint restore fails

Impact

A bug in containerd's CRI plugin on Linux can cause containerd to leak read-only mounts and pinned snapshots when restoring a container from a checkpoint image fails. Repeatedly creating containers from a checkpoint image with malformed metadata or a base image that cannot be pulled can exhaust the host mount table and disk space indefinitely. In Kubernetes, this resource exhaustion can prevent containerd and the kubelet from pulling images or starting new pods on the node.

Patches

This bug has been fixed in containerd 2.3.7 and 2.2.10. Users should update to these versions to resolve the issue. To release resources from mounts leaked prior to the update, administrators must unmount any lingering /tmp/checkpoint* mount points on the host (or reboot the node) so containerd can garbage-collect the pinned snapshots.

Workarounds

containerd 2.4 does not support restore via the CRI plugin and is not vulnerable to this bug.

In containerd 2.3 and 2.2, disable CRI checkpoint and restore support by setting enable_criu = false under [plugins."io.containerd.cri.v1.runtime"] (or [plugins."io.containerd.grpc.v1.cri"] in config version 2) in containerd's configuration, or ensure enable_experimental_restore_via_create is set to false (the default starting in containerd 2.3.4 and 2.2.7). Restrict pod image references to trusted registries (for example, using a Kubernetes ValidatingAdmissionPolicy or admission webhook).

Credits

The containerd project would like to thank @IamwhatIamSY for responsibly disclosing this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this advisory:

• Open an issue in containerd
• Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

• Report a new vulnerability
• Email us at [security@containerd.io](mailto:security@containerd.io)