GPU VulnDB

Database/Container, Kubernetes & orchestration

CRI-O: pod log path traversal lets a pod creator unmount arbitrary host paths

CVSS 6.6CVE-2025-0750Container, Kubernetes & orchestrationcurated

Impact

A tenant who can create and delete pods can drive CRI-O's log mount/unmount helpers into a path outside the intended log directory and unmount arbitrary host paths. Unmounting something the node depends on - the container storage mount, a device mount, an NFS or Lustre scratch mount - breaks workloads that are still running and can take the kubelet or the container runtime out of service. On a GPU node this is expensive: the node has to be drained and brought back, and drain is slow when long-running training jobs or stateful inference replicas are pinned to the accelerators. Confidentiality impact is limited; the real cost is availability on a node you cannot cheaply replace.

Who can reach it

Authenticated tenant with Kubernetes permissions to create and delete pods on the node (namespace-level pod create is enough). Local to the node from the runtime's perspective; no host access needed.

What to do

Update CRI-O to the fixed build for your OpenShift 4.17/4.18 stream (RHSA-2025:1122) and restart the CRI-O service on each node; a CRI-O restart on a node running workloads is normally done with the node drained, so plan this as a rolling node-drain across the fleet. Until patched, restrict who can create pods and avoid giving untrusted tenants direct pod-create in shared clusters.

References

Related entries

All Container, Kubernetes & orchestration entries

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.