Database/Container, Kubernetes & orchestration
CRI-O: "cr8escape": kernel sysctl injection via pod spec gives container escape and arbitrary code execution
Impact
"cr8escape": kernel sysctl injection via pod spec gives container escape and arbitrary code execution as root on the node
Who can reach it
Any cluster user who can deploy a pod
What to do
Emergency CRI-O upgrade on all nodes; drain and recreate pods. Add admission policy blocking sysctl values with newlines
Fleet impact
How widespread
Common - CRI-O is the default runtime on OpenShift and on several K8s distros neoclouds resell; less common than containerd but not niche
Cost to remediate
daemon-restart - upgrading CRI-O restarts the node's container runtime, which on most configurations restarts all pods on that node, so effectively node-drain for GPU workloads mid-training
Why it hits the whole fleet
Anyone who can create a pod (i.e. any tenant with namespace access) sets arbitrary host kernel parameters via sysctls, abuses kernel.core_pattern and gets root code execution on *any* node in the cluster
References
Related entries
- CRI-O: Malicious container creates a symlink via directory traversal and gets arbitrary host read/writeCVE-2024-5154 · CRI-OHigh
- CRI-O: Crafted environment variable injects arbitrary lines into /etc/passwdCVE-2022-4318 · CRI-OHigh
- CRI-O: Unbounded ExecSync output exhausts node memory or diskCVE-2022-1708 · CRI-OHigh
- CRI-O: Incorrect supplementary group handling leads to information disclosure between workloadsCVE-2022-2995 · CRI-OHigh
- CRI-O: Containers started with non-empty default inheritable capabilitiesCVE-2022-27652 · CRI-OMedium
- CRI-O: All pod processes share one memory cgroup, so a workload OOM kills conmon and destabilises the nodeCVE-2019-14891 · CRI-OMedium
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.