CVE-2022-0492: Linux Kernel cgroups v1 — Container Escape and Privilege Escalation

Background

Control groups (cgroups) is a Linux kernel feature that limits and isolates the resource usage of process groups. Version 1 of cgroups (cgroups v1) includes a release_agent mechanism: when all processes in a cgroup exit, the kernel executes the binary path specified in the release_agent file. This callback is designed to enable clean-up operations when a cgroup becomes empty.

CVE-2022-0492 is an improper authorisation vulnerability (CWE-287, CWE-862) in kernel/cgroup/cgroup-v1.c that allows a process with CAP_SYS_ADMIN within a user namespace — such as an unprivileged container — to write to the release_agent file of a cgroup outside its namespace, and then trigger execution of that binary as root on the host kernel. The vulnerability was disclosed and patched in February 2022 and was added to CISA’s Known Exploited Vulnerabilities catalogue on 2 June 2026 with a required remediation date of 5 June 2026.

The CISA KEV addition, four years after the original disclosure, reflects continued detection of exploitation in containerised environments — particularly against Kubernetes clusters where container isolation is expected but not fully enforced.

Technical Mechanism

The root cause is in cgroup_release_agent_write() in kernel/cgroup/cgroup-v1.c. This function, which handles writes to the release_agent cgroup control file, did not properly verify that the calling process held CAP_SYS_ADMIN in the initial user namespace — only that it held the capability in some user namespace.

A containerised process running as root inside the container (and therefore holding CAP_SYS_ADMIN within the container’s user namespace) could:

1. Create a new cgroup hierarchy and mount cgroups v1 within the container’s filesystem namespace
2. Write a malicious script path to the release_agent file — because the kernel incorrectly accepted the user-namespace-scoped CAP_SYS_ADMIN as sufficient authorisation
3. Create a process in the cgroup and then kill it, causing the cgroup to become empty
4. Trigger kernel execution of the malicious release_agent path — with host root privileges, outside any container namespace

The fix (commit 24f600856418) tightens the capability check in cgroup_release_agent_write() to require CAP_SYS_ADMIN in the initial user namespace specifically, rejecting capability grants scoped to child namespaces.

Exploitation requirements:

• Local access (or code execution inside a container)
• Ability to create new user namespaces (required unless the attacker already has root inside a privileged container)
• cgroups v1 available and mountable (standard in most Linux distributions; cgroups v2-only hosts are not affected by this specific path, though they may expose separate issues)

User namespace creation is controlled by /proc/sys/kernel/unprivileged_userns_clone (Debian/Ubuntu) or kernel.unprivileged_userns_clone. Systems with this disabled, or with AppArmor/SELinux policies that prevent namespace creation from container contexts, have significant mitigation in place.

Real-World Exploitation Evidence

Public PoC implementations were released shortly after the February 2022 disclosure, including a container escape checker from Sofiane Hamlaoui and a containerised exploit by Palo Alto Networks Unit 42. The exploit is reliable and well-documented.

CISA’s 2026 KEV addition indicates continued active exploitation detected in production environments. The most likely attack scenarios are:

Kubernetes node compromise via misconfigured pods. Pods running with privileged: true or allowPrivilegeEscalation: true, combined with unrestricted user namespace creation, provide the preconditions for this exploit. An attacker with code execution in such a pod can escape to the Kubernetes node’s host operating system.

Container breakout in shared container hosting environments. Multi-tenant container platforms where tenant containers run as root (rather than as an unprivileged UID) are directly affected.

Post-exploitation privilege escalation. Threat actors with low-privilege access to a Linux host can use this vulnerability (combined with user namespace creation) to escalate to root without requiring a memory corruption exploit.

Impact Assessment

Successful exploitation of CVE-2022-0492 provides:

• Host root access: Execution of arbitrary commands as root on the container host, bypassing all container isolation boundaries.
• Full Kubernetes node compromise: From a misconfigured pod, an attacker can take ownership of the underlying node, accessing all other pods, secrets, and workloads running on that node.
• Cluster credential access: Host root access exposes Kubernetes service account tokens, kubeconfig files, and etcd credentials stored on the node, enabling lateral movement to the API server and broader cluster compromise.
• Persistent access: Root on the host enables installation of kernel modules, modification of container runtime binaries, and other persistence mechanisms that survive container restarts.
• Data exfiltration: All volume mounts from all containers on the node, including secrets and ConfigMaps, are accessible from host root context.

Affected Versions

All Linux kernel versions from 2.6.24 through 5.16.5 are affected, spanning essentially every kernel that includes cgroups v1:

Distribution kernels containing the fix:

Remediation Steps

1. Update to a patched kernel version:

   • Ubuntu: sudo apt update && sudo apt upgrade linux-image-generic
   • RHEL/CentOS/Rocky: sudo yum update kernel
   • Debian: sudo apt-get install linux-image-amd64 (Bullseye 5.10.103-1+)

2. Short-term workaround — disable unprivileged user namespace creation:

   # Temporary (until next reboot)
   echo 0 > /proc/sys/kernel/unprivileged_userns_clone
   
   # Persistent (Debian/Ubuntu)
   echo "kernel.unprivileged_userns_clone=0" >> /etc/sysctl.conf
   sysctl -p

3. Kubernetes hardening:

   • Audit all pods for privileged: true or allowPrivilegeEscalation: true and remove unless operationally required
   • Apply a PodSecurity admission controller that blocks privileged container creation
   • Consider restricting user namespace creation via seccomp profiles or OPA/Gatekeeper policies

4. Container runtime hardening:

   • Verify that AppArmor profiles on Docker and containerd are active — default profiles on many Ubuntu installations block the user namespace creation step
   • Confirm SELinux enforcing mode is active on RHEL-based systems

Detection Guidance

Kernel audit log (auditd):

Monitor for unshare syscall usage from container contexts:

-a always,exit -F arch=b64 -S unshare -k namespace_creation
-a always,exit -F arch=b32 -S unshare -k namespace_creation

Flag instances where unshare is called with CLONE_NEWUSER from container namespaces.

Falco rule:

- rule: Suspicious Namespace Creation in Container
  desc: Detect user namespace creation inside a container — precondition for CVE-2022-0492
  condition: >
    spawned_process and
    container and
    proc.name = "unshare" and
    proc.args contains "user"
  output: >
    User namespace created inside container (user=%user.name cmd=%proc.cmdline container=%container.name)
  priority: WARNING

Indicators of compromise:

• Unexpected cgroup mounts within container filesystem namespaces
• release_agent files containing non-standard paths or shell scripts
• Processes spawned from kthreadd (PID 2’s descendants) that map to user-supplied paths
• Root-owned processes appearing outside expected container PIDs after container exits

Timeline

References

• NVD — CVE-2022-0492
• CISA Known Exploited Vulnerabilities Catalogue
• Linux kernel fix commit 24f600856418
• Palo Alto Networks Unit 42 — CVE-2022-0492 Container Escape Analysis
• Ubuntu Security Notice USN-5302-1