GPU VulnDB

Database/Container, Kubernetes & orchestration

containers/storage: malicious image symlink causes Podman/Buildah/CRI-O to hang or OOM the host

CVSS 6.5CVE-2024-9676Container, Kubernetes & orchestrationcurated

Impact

When a container is started with an automatically assigned user namespace, containers/storage reads /etc/passwd from inside the image without checking that it is a symlink. A crafted image can point that path at an arbitrary host file, and reading it drives the runtime into a hang or an out-of-memory kill. In practice this is a denial of service against the node's container runtime triggered by whoever can get an image pulled and run. On a GPU node this means workloads on the box stop being schedulable or get killed by the OOM reaper, and recovery is a runtime restart with the node drained - a node you cannot drain cheaply when multi-hour training jobs hold the accelerators. The symlink-following also means host file contents reach the storage library, though the advisory describes the outcome as availability only.

Who can reach it

Remote but authenticated: anyone who can supply or reference a container image that gets run on the node with an automatically assigned user namespace (--userns=auto with Podman or Buildah; CRI-O in the equivalent configuration). No host login required.

What to do

Update podman / buildah / cri-o and the containers/storage they ship on RHEL 8, RHEL 9 and OpenShift 4.12-4.15 (RHSA-2024:8418, RHSA-2024:8428, RHSA-2024:8437, RHSA-2024:10289), then restart the runtime - on a Kubernetes node that means draining it and restarting CRI-O. Interim mitigation: do not run untrusted images with automatic user-namespace assignment, and restrict image sources to a registry you control.

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.