01
What the vulnerability does
When CRI-O restores a container from a CRIU checkpoint, the restored process keeps the security attributes of the process that was checkpointed: its UID, capabilities, NoNewPrivs and seccomp filters. The security context specified for the destination container is ignored.
The CRI-O advisory adds the detail that makes this hard to see: both the Kubernetes control plane and CRI-O report the requested security context rather than the actual process state, which hides the escalation from admission controllers, audit logs and monitoring. CRI-O scores it CVSS 3.1 9.9, with a changed scope.
02
Affected and fixed versions
From the CRI-O advisory.
- Affected: 1.36.5 and earlier in the 1.36 line, 1.35.8 and earlier, 1.34.13 and earlier.
- Fixed: 1.37.0, 1.36.6, 1.35.9 and 1.34.14. These add the container_level_enabled option, which defaults to checkpoint_only and blocks the restore path.
- Still vulnerable after upgrading if container_level_enabled is explicitly set to checkpoint_restore. The advisory states there is no way to prevent the bypass as long as restore is available.
03
Check your nodes
Read the runtime version from the Kubernetes API, then check the checkpoint settings CRI-O is running with on each node.
kubectl get nodes -o custom-columns=\
NODE:.metadata.name,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion
# On the node:
crio config 2>/dev/null | grep -E \
'container_level_enabled|enable_criu_support'04
What the API cannot tell you, and what can
The pod spec, the container status and the audit log all describe the security context that was requested. To see what a restored container actually runs with, read the process state the kernel enforces.
A container whose spec drops capabilities or sets a non-root user, but whose first process shows Uid 0, a full CapEff mask, NoNewPrivs 0 or Seccomp 0, is the mismatch this vulnerability creates. A restore also runs CRIU on the node, which any sensor recording process executions will capture with the pod it produced.
# On the node: the container's first process
crictl inspect <container-id> | grep -m1 '"pid"'
grep -E '^(Uid|CapEff|NoNewPrivs|Seccomp):' \
/proc/<pid>/status05
Fixing it
Upgrade to 1.37.0, 1.36.6, 1.35.9 or 1.34.14 and do not set container_level_enabled to checkpoint_restore.
The advisory's workarounds for nodes that cannot be upgraded yet: set container_level_enabled to checkpoint_only or none in the [crio.checkpoint_restore] table, or set enable_criu_support = false to turn checkpoint and restore off entirely.
06
Where Primod fits
Primod's per-node eBPF sensor records process executions and lineage with the workload they belong to, so a criu restore nobody planned, and the processes it brought back, are visible against the pod they ran in. That is evidence of what happened; the configuration change and the upgrade are the fix.
Frequently asked questions
- Is this the same bug as the containerd one?
- It is the same class of problem, in a different runtime. The CRI-O advisory references containerd's GHSA-p7v4-vr35-mj6f as the equivalent advisory. Each runtime has its own fixed versions.
- Does turning off checkpointing break kubectl checkpoint or forensic checkpoints?
- checkpoint_only keeps checkpointing and blocks only restore, which is the default in the fixed versions. none, or enable_criu_support = false, turns both off.
- Why would audit logs miss it?
- The advisory says both the Kubernetes control plane and CRI-O report the requested security context rather than the actual process state. Audit logs record API requests, so they show what was asked for.
