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
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.