GPU VulnDB

Database/Container, Kubernetes & orchestration

CRI-O: arbitrary systemd property injection via a pod annotation gives action on the host

CVE-2024-3154Container, Kubernetes & orchestrationcurated

Impact

Anyone able to create a pod carrying an arbitrary annotation can have CRI-O set an arbitrary systemd property on the container's scope unit, which translates into arbitrary action on the node. On a GPU fleet the blast radius is the whole node: the driver state, every co-tenant container on it, the /dev/nvidia* device nodes, and whatever credentials the kubelet holds. The CVSS PR:H rating reflects an assumption about who can set annotations; on multi-tenant clusters where namespace users submit their own pod specs, that is effectively any tenant. Red Hat's record ties this to OpenShift 4.12-4.15 and 3.11.

Who can reach it

Any authenticated Kubernetes user who can create a pod with arbitrary annotations in a namespace that schedules onto CRI-O nodes. No node or host access needed.

What to do

Update CRI-O and restart it on every node (RHSA-2024:2669, 2672, 2784, 3496 cover the affected OpenShift streams). Restarting CRI-O recycles the container runtime, so on GPU nodes running long training jobs this has to be a rolling drain-and-update rather than an in-place daemon bounce. Until nodes are updated, an admission policy that rejects unknown or non-allowlisted pod annotations blocks the delivery path.

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.