CRIU: a container process can spoof its saved credentials and restore with root UID and capabilities

Impact

A process inside a container registers a restartable-sequence critical section that hijacks CRIU's parasite code injection at checkpoint time, so the credentials written into the checkpoint image are attacker-chosen. On restore the process returns with zeroed UIDs/GIDs and elevated capabilities. On a GPU fleet this only bites where checkpoint/restore is actually in use, typically to pause or migrate long training jobs. Red Hat's own analysis bounds it hard: checkpointing requires root via podman or cluster-admin RBAC and cannot be started from inside the container, the kubelet checkpoint API is not RBAC-configured by default on OpenShift 4.17+ and needed explicit opt-in before that, enforced user namespaces make spoofed capabilities namespace-scoped, and SELinux container_t, surviving seccomp filters and mount-namespace ownership checks each block escalation independently. Treat it as a real credential-integrity bug in the checkpoint path, not a directly reachable container escape.

Who can reach it

A workload running inside a container, but only when a privileged operator or controller actually checkpoints that container. Not triggerable by the tenant alone; no network path.

What to do

Take the CRIU update from your distribution once available; the upstream fix is checkpoint-restore/criu PR #3097 and Red Hat tracks per-product state on its CVE page. If no fixed package exists for your release yet, leaving container checkpoint/restore disabled (the default on OpenShift) removes the exposure. Package update, no node reboot.

References