CVE-2022-0492

What is Linux cgroups?

Control groups (cgroups) is a Linux kernel mechanism that partitions processes into groups and manages their resource usage — CPU, memory, disk I/O, and network bandwidth. cgroups v1 is the original implementation, deployed on virtually every Linux distribution and forming the isolation foundation for Docker, Kubernetes, LXC, and cloud container runtimes. Because so many systems depend on it, vulnerabilities in the cgroups subsystem carry outsized impact across cloud and enterprise infrastructure.

Overview

CVE-2022-0492 is a privilege escalation and container escape vulnerability in the Linux kernel's cgroups v1 subsystem. The flaw lies in the release_agent feature — a file that, when written with a program path, causes the kernel to execute that program with full root privileges on the host whenever a cgroup becomes empty. The kernel failed to verify that the writing process held CAP_SYS_ADMIN in the initial (host) user namespace, checking only the process's own namespace instead. This allowed unprivileged processes inside a user namespace — including containerized environments — to write to release_agent and achieve host-level code execution.

Discovered by researchers at Palo Alto Networks Prisma Cloud, the vulnerability was patched in March 2022. CISA added it to the Known Exploited Vulnerabilities catalog in June 2026.

Affected Versions

Distribution kernels (Ubuntu, RHEL, Debian, SUSE) shipped backported patches in March 2022.

Technical Details

Root cause — wrong namespace for capability check (CWE-287)

The cgroups v1 release_agent write handler called ns_capable(current_user_ns(), CAP_SYS_ADMIN) instead of capable(CAP_SYS_ADMIN). The ns_capable() form is satisfied by capabilities within any user namespace, including a new unprivileged namespace created with unshare(2). The capable() form requires the capability in the initial namespace — the host — and is what the check should have used.

When a cgroup empties, the kernel forks a process in the initial user namespace and executes the release_agent path as UID 0, outside any container namespace constraints. An attacker who can write to release_agent therefore escapes all container boundaries.

Two exploitation paths:

1. Unprivileged user namespace (default-on Ubuntu/Debian): A non-root user calls unshare -Urm to create a new user namespace with a mapped root. Inside, they mount a tmpfs cgroup, write a payload to release_agent, then trigger the cgroup to empty. The payload executes on the host as root — a full container escape from an unprivileged starting point.

2. Privileged container (--privileged or SYS_ADMIN capability granted): A process already inside a container with CAP_SYS_ADMIN can write directly to release_agent without the namespace indirection. This is the simpler path and is commonly available in Kubernetes pods running with elevated privileges.

The attack is entirely local, requires no network access, and completes in a single shell session with no race condition.

Discovery

Discovered by Yuval Avrahami and Yoav Strauss of Palo Alto Networks Prisma Cloud and reported to the Linux kernel security team in early 2022. The fix was authored and merged by kernel maintainer Tejun Heo via commit 24f6008.

Exploitation Context

Active exploitation has been confirmed. The technique is particularly impactful in Kubernetes and Docker environments where:

• Containers run with --privileged or with SYS_ADMIN in their capability set (common in storage, networking, and observability sidecar containers)
• The host kernel has unprivileged user namespaces enabled — the Ubuntu/Debian default (kernel.unprivileged_userns_clone=1)
• Container escape detection tooling (Falco, Sysdig) is absent or not alerting on cgroup mount activity

The CVE's addition to the CISA KEV catalog in June 2026 — four years after the initial disclosure — indicates continued active exploitation in unpatched or newly deployed systems. The technique is well-documented in public exploit repositories and container escape toolkits, lowering the barrier for less sophisticated attackers.

Remediation

1. Patch the kernel — update to the patched stable version for your distribution's LTS stream (Ubuntu: 5.15.0-70+, RHEL 8: 4.18.0-372+, Debian 11: 5.10.103+)
2. Disable unprivileged user namespaces if not required — Ubuntu/Debian: sysctl -w kernel.unprivileged_userns_clone=0; RHEL/Fedora: sysctl -w user.max_user_namespaces=0; persist in /etc/sysctl.d/
3. Remove --privileged and drop CAP_SYS_ADMIN from container definitions — use --cap-drop=ALL and add back only specific capabilities that are actually required
4. Enable AppArmor or SELinux container profiles — distribution-default runtime profiles block cgroup filesystem writes from containers
5. Migrate to cgroups v2 — the unified cgroups v2 hierarchy does not implement release_agent and is not affected by this class of vulnerability
6. Audit Kubernetes securityContext — scan manifests for privileged: true or capabilities.add: [SYS_ADMIN] and remove where unnecessary