Linux cgroups release_agent container escape (CVE-2022-0492)

In February 2022, researchers at Palo Alto Networks' Unit 42 disclosed CVE-2022-0492, a privilege-escalation and container-escape vulnerability in the Linux kernel's cgroup v1 release_agent mechanism. The flaw allows a process with CAP_SYS_ADMIN inside a container — a capability present in many "privileged" or loosely-hardened container configurations — to write to the release_agent file of a cgroup hierarchy and get arbitrary code executed on the host, outside the container's namespace boundary. In practical terms: an attacker who compromises an application running in an under-hardened container can, in a handful of shell commands, pivot from "I own a container" to "I own the node."

This isn't a theoretical corner case. release_agent abuse for container escape had already been demonstrated in prior research (the technique predates this CVE), but CVE-2022-0492 formalized that the kernel's own capability check was insufficient to prevent a namespaced, unprivileged-relative-to-the-host process from triggering a host-context callback. Because so many production fleets still run cgroup v1, and because CAP_SYS_ADMIN is one of the most commonly over-granted capabilities in the wild (often added to satisfy an application's need for some unrelated privileged operation), this vulnerability sits squarely in the "quiet but dangerous" category that supply chain security teams need to actively hunt for rather than wait to hear about.

What is release_agent and why does it matter

Control groups (cgroups) are the Linux kernel primitive that containers use to limit and account for resources like CPU, memory, and I/O. In cgroup v1, each cgroup hierarchy supports a notify_on_release flag and a release_agent file. When the last process in a cgroup exits and notify_on_release is set to 1, the kernel executes the path stored in release_agent — and critically, it executes that path in the context of the host's initial namespace, with full host filesystem visibility, regardless of which container or namespace the write to release_agent originated from.

The vulnerable code path checked whether the calling process held CAP_SYS_ADMIN, but did not adequately verify that the capability was meaningful in the context of the host (as opposed to merely within the caller's own user/cgroup namespace). Combined with the ability to mount the cgroup filesystem read-write inside a container — which is possible when a container is run with --privileged, with CAP_SYS_ADMIN explicitly added, or under certain misconfigured Kubernetes securityContext settings — an attacker can:

1. Mount a fresh cgroup hierarchy inside the container.
2. Enable notify_on_release for that hierarchy.
3. Overwrite release_agent with a path to an attacker-controlled script (frequently exfiltrated via a bind-mounted or written file with a known host path).
4. Spawn and immediately kill a process in the cgroup to trigger the kernel's release-agent callback.
5. Watch the payload execute as root, on the host, outside any container boundary.

Affected versions and components

• Component: Linux kernel, cgroup v1 subsystem (kernel/cgroup/cgroup-v1.c).
• Affected kernels: Mainline Linux kernels prior to the fix landed in early February 2022, spanning a very wide range of long-term-support branches (the bug had existed in the cgroup v1 code for years before it was formally tracked as a CVE).
• Distribution exposure: Any distribution shipping an unpatched kernel — this included widely deployed enterprise and cloud-provider kernel builds until vendors backported the fix through their respective update channels.
• Container/runtime exposure: Docker, containerd, CRI-O, and Kubernetes nodes are all exposed at the orchestration layer if (a) the underlying node kernel is unpatched, and (b) a container is able to obtain CAP_SYS_ADMIN and write access to a cgroup v1 hierarchy. This typically requires privileged: true, an explicit SYS_ADMIN capability addition, or a permissive PodSecurity/AppArmor/SELinux posture — the vulnerability is not exploitable from a default, unprivileged container without one of these additional misconfigurations stacked on top.
• Not affected: Hosts running cgroup v2 exclusively are not vulnerable to this specific release_agent vector, since cgroup v2 removed the release_agent mechanism entirely.

Severity, exploit context, and known exploitation

CVE-2022-0492 carries a CVSS v3.1 base score of 7.8 (High), reflecting local-vector, low-complexity exploitation with high impact to confidentiality, integrity, and availability once the capability and mount preconditions are met. It has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring has stayed in the low range, consistent with the fact that exploitation depends on a compounding misconfiguration (privileged/SYS_ADMIN containers) rather than being remotely triggerable against default deployments. That said, "low EPSS" should not be read as "low priority" — EPSS models internet-wide opportunistic exploitation likelihood, not the blast radius inside an organization that does run privileged workloads, which is common in CI runners, monitoring/security agents, and legacy container migrations. In those environments this vulnerability is a direct, well-documented path to full node compromise.

Timeline

• ~January 2022: Researchers Yiqi Sun and Sun Ke, expanding on prior public research into release_agent-based escapes, formally identify and report the insufficient-capability-check issue to the Linux kernel security team.
• February 3, 2022: Kernel maintainers land the fix, tightening the release_agent write path so that the operation is properly scoped to the initial (host) user namespace rather than trusting a namespaced CAP_SYS_ADMIN check alone.
• February 2022: CVE-2022-0492 is assigned and distribution vendors begin backporting the patch into stable and LTS kernel branches.
• March 2022: Unit 42 publishes detailed public research documenting the exploit chain, proof-of-concept mechanics, and detection guidance, driving broader industry awareness.
• Ongoing: The technique remains a staple check in container-escape tooling and CIS Docker/Kubernetes Benchmark guidance, since the underlying pattern (privileged containers + cgroup v1 + writable release_agent) persists on any host that hasn't both patched the kernel and hardened container capabilities.

Remediation steps

1. Patch the kernel. Confirm your distribution's kernel package includes the February 2022 cgroup v1 fix. Check vendor advisories (Red Hat, Ubuntu, Debian, SUSE, Amazon Linux, etc.) for the specific backport version and update all container hosts and Kubernetes nodes.
2. Eliminate unnecessary privileged containers. Audit every workload running with --privileged or an explicit SYS_ADMIN capability grant. In Kubernetes, this means reviewing securityContext.privileged and securityContext.capabilities.add across all Pod specs, admission policies, and Helm chart defaults — including third-party charts pulled in as dependencies.
3. Enforce least-capability defaults. Drop all capabilities by default (capabilities.drop: ["ALL"]) and add back only what a workload demonstrably needs. Use Pod Security Admission (restricted profile) or OPA/Gatekeeper/Kyverno policies to block privileged and SYS_ADMIN pods outside explicitly approved exceptions.
4. Migrate to cgroup v2 where feasible. Cgroup v2 removes the release_agent interface entirely, closing this class of attack. Most current distributions (RHEL 9+, Ubuntu 22.04+, recent Kubernetes/containerd/Docker releases) default to cgroup v2 — verify with mount | grep cgroup or stat -fc %T /sys/fs/cgroup.
5. Mount cgroup filesystems read-only inside containers when full removal of privileged access isn't immediately possible, and use seccomp/AppArmor profiles to block the specific syscalls involved in cgroup manipulation as a compensating control.
6. Add runtime and admission-time detection. Alert on containers writing to release_agent, notify_on_release, or mounting /sys/fs/cgroup read-write, and flag any newly scheduled Pod requesting SYS_ADMIN or privileged mode for security review before it reaches production.

How Safeguard Helps

Kernel CVEs like this one are exactly where noisy, unprioritized vulnerability lists fail security teams — the CVE alone doesn't tell you whether any given node is actually exploitable in your environment. Safeguard's reachability analysis correlates kernel and base-image versions against your actual running fleet and flags only the nodes and workloads where the vulnerable cgroup v1 path is present and a container in that environment holds the SYS_ADMIN/privileged preconditions needed to trigger it, cutting through fleet-wide noise to the handful of hosts that matter. Griffin AI continuously reasons over your Kubernetes manifests, Helm charts, and admission policies to surface privileged and over-capable container configurations — the actual enabling misconfiguration behind CVE-2022-0492 — before they ship, not after an incident. Safeguard's SBOM generation and ingest pipeline tracks kernel and container runtime versions across every node and image so you have a real-time, auditable inventory of exposure instead of a spreadsheet that's stale the day after you build it. And where remediation is mechanical — bumping a base image, patching a kernel package reference in IaC, or tightening a securityContext block to drop unnecessary capabilities — Safeguard's auto-fix PRs open the change directly against your repository, turning a multi-team coordination problem into a one-click review.