CRI-O: oversized /etc/passwd in a tenant image exhausts node memory when runAsUser is unknown

Impact

When a pod sets securityContext.runAsUser to a UID that does not exist in the image, CRI-O tries to create the user and reads the container's entire /etc/passwd into memory first. A tenant shipping an image with a deliberately enormous /etc/passwd turns that into node-level memory exhaustion, and the OOM killer then reaps whatever else is resident. On a GPU node this is worse than a normal noisy-neighbour event: the co-located victims are long-running training jobs and loaded inference replicas whose model weights took minutes to page into GPU memory, and the attack costs the tenant nothing but an image push.

Who can reach it

Any tenant who can schedule a pod on the node with an image they control and a securityContext.runAsUser value that does not exist in that image. Authenticated cluster access is required; no node-level access is.

What to do

Update CRI-O per the Red Hat advisory (tracked for OpenShift Container Platform 4; the record does not name a fixed CRI-O version, so take it from the vendor page for your release). Picking up a new crio binary means restarting the runtime on each node, which restarts its containers, so plan it as a rolling drain and cordon across the fleet rather than an in-place daemon bounce. Before the rollout, an admission policy that rejects pods whose runAsUser is not present in the image, or that caps image layer content, narrows the trigger.

References