Robertprast

The CRI checkpoint import process fails to validate image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force the system to pull a malicious image and assign it an arbitrary local tag, poisoning the node's local image cache. If other pods on the same node use the poisoned tag with an `IfNotPresent` or `Never` pull policy, they will execute the malicious image instead of the legitimate one, allowing the attacker to execute arbitrary code under the victim pod's identity. Additionally, some related issues can lead to host-root command execution during restore.

A bug in the CRI plugin allows the propagation of labels from an image config, specifically the `LABEL` instruction in a Dockerfile, to a container without proper validation. This can lead to the execution of arbitrary commands on the host system if a plugin that consumes container labels for its operations is used.

A bug in the CRI plugin allows the restoration of `container.log` from a checkpoint image without validating a symlinked path. This can lead to an arbitrary file read on the host system when using `kubectl logs`.

The CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. Instead of relying solely on the pod's create-time specification, the system preserves CDI-related annotations from the checkpoint archive. This allows a user with pod creation permissions to bypass Kubernetes resource allocation and device plugin enforcement by injecting arbitrary CDI edits, such as device nodes and host mounts, into the restored container. This issue requires CDI to be enabled on the node and the presence of a matching host CDI specification for the requested device.