
Linux cgroups
Linux kernel control-groups feature isolating container resources; cgroups v1 release_agent is the CVE-2022-0492 attack surface.
Last refreshed: 7 June 2026
Does migrating to cgroups v2 fully protect against the CVE-2022-0492 container-escape class?
Timeline for Linux cgroups
Old Linux container bug back in the wild
Cybersecurity: Threats and DefencesBackground
Linux cgroups (control groups) is a Linux kernel feature that organises processes into hierarchical groups to isolate and limit their consumption of CPU, memory, I/O, network bandwidth and other resources. First merged into the Linux kernel in 2008 (version 2.6.24) and developed through cgroups v2 from kernel 4.5 Onward, cgroups are the foundational kernel primitive underlying all major container runtimes, including Docker, containerd and podman, and container orchestration platforms such as Kubernetes. The orchestration layer uses cgroups to fence workloads inside containers so that a single noisy or compromised application cannot consume resources allocated to other containers on the same host.
The cgroups v1 release_agent mechanism is the attack surface of CVE-2022-0492. Release_agent is a legitimate feature: it allows a cgroups hierarchy to invoke a user-specified executable when all processes in a cgroup exit, intended for resource-cleanup callbacks. The vulnerability arises because the kernel does not validate whether the process writing to the release_agent file holds adequate privilege relative to the host namespace. A process inside a container with cgroups v1 access can write an arbitrary command to release_agent on the host and trigger execution at host-root level when its container exits. This constitutes a full container escape: attacker code running inside the container gains root-level execution on the underlying host.
Cgroups v2, which became the default in modern distributions (Fedora 31+, Debian 11+, Ubuntu 22.04+), removes the release_agent mechanism in its architecture, eliminating this entire attack class. Organisations still running cgroups v1 (common in older Kubernetes cluster configurations and legacy Docker setups) remain exposed if the February 2022 kernel patch has not been applied.