CRI-O: restored checkpoints re-apply archive mounts, bypassing pod-spec host mount validation

Impact

CRI-O restores a container's mounts from the checkpoint archive rather than from the validated pod spec, so the admission and pod-spec checks that normally decide which host paths a container may see do not apply to a restored container. Someone able to call the restore endpoint can bring up a pod holding host mounts it was never authorized for, which on a GPU node means reaching host paths such as device nodes, driver state, or kubelet credentials outside the tenant's namespace. On a shared GPU cluster this collapses the boundary that keeps one tenant's workload off the host filesystem. Exploitation requires access to the kubelet or CRI-O socket, which is itself a privileged position, so this is an escalation of an already-elevated foothold rather than a path in from a plain pod.

Who can reach it

A local actor with access to the kubelet or CRI-O socket on the node - authenticated/privileged access to that socket is required; it is not reachable from an ordinary unprivileged pod.

What to do

Update CRI-O to a fixed build via the Red Hat errata for your OpenShift or RHEL stream and restart the CRI-O daemon on each node, which restarts the containers on that node - in practice, drain and roll nodes one at a time. If checkpoint/restore is not used, keeping the feature disabled removes the exposure without a node roll.

References