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 Defences- What are Linux cgroups and why do they matter for container security?
- Linux cgroups (control groups) is the kernel feature that Docker, containerd and Kubernetes use to isolate container workloads from each other and from the host. They limit CPU, memory and I/O per container. The cgroups v1 release_agent mechanism contained CVE-2022-0492, a container-escape vulnerability allowing a process inside a container to execute code as host root. Cgroups v2, the default in modern distributions, removes this attack surface.Source: Linux kernel documentation, Trail of Bits cgroups analysis
- Is my Docker setup vulnerable to the cgroups container-escape CVE-2022-0492?
- If you are running a Linux kernel without the February 2022 security patch, using cgroups v1, and your containers lack AppArmor or SELinux profiles, you are potentially vulnerable. Check your kernel version with `uname -r`, verify the patch is applied, and confirm your distribution has shipped the fix. Migrating to cgroups v2 (available in Ubuntu 22.04+, Fedora 31+, Debian 11+) eliminates the entire release_agent attack class.Source: Trail of Bits, CISA KEV advisory
Background
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.