GPU VulnDB

Database/Container, Kubernetes & orchestration

containerd: CRI ExecSync I/O drain never times out, leaking goroutines until the OOM killer takes the runtime

CVSS 6.8CVE-2026-53495Container, Kubernetes & orchestrationcurated

Impact

An exec probe or lifecycle hook whose command spawns a long-lived background child that keeps the stdout/stderr pipes open leaves containerd's drainExecSyncIO goroutine blocked forever - the drain phase had no timeout and ignored request-context cancellation. Repeated ExecSync calls, which on Kubernetes means every exec-probe interval, accumulate blocked goroutines and host memory until the OOM killer terminates containerd. On a GPU node that takes down the runtime for every pod on the box, and GPU workloads are exactly the ones that are expensive to reschedule: allocations must be re-granted, containers re-pulled, and long training jobs restart from checkpoint. A tenant that controls its own pod spec controls the probe command, so this is reachable without any host privilege. Only Linux deployments using containerd's CRI implementation are affected.

Who can reach it

A tenant able to create a pod with an exec probe or a lifecycle hook on the node - namespace-level Kubernetes access, no host privilege. Also reachable unintentionally by a badly behaved workload.

What to do

Upgrade containerd to 1.7.35, 2.0.12, 2.2.8 or 2.3.5 and restart the containerd daemon on each node. Restarting containerd does not by itself kill running containers, but on most distributions the node should be drained first to avoid probe and stream disruption during the restart. Until patched, audit exec probes and lifecycle hooks for commands that leave background children holding stdio, and watch containerd RSS and goroutine count.

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.