CVE-2022-0492: Linux Kernel Privilege Escalation Flaw

CVE-2022-0492 Overview

A vulnerability was found in the Linux kernel's cgroup_release_agent_write function in kernel/cgroup/cgroup-v1.c. This flaw, under certain circumstances, allows the use of the cgroups v1 release_agent feature to escalate privileges and bypass namespace isolation unexpectedly. The vulnerability enables local attackers with low privileges to potentially escape container environments and gain elevated access to the host system.

Critical Impact
This vulnerability allows local privilege escalation and container escape through exploitation of the cgroups v1 release_agent mechanism, potentially compromising the isolation boundaries that containerized environments depend on for security.

Affected Products

Linux Kernel (multiple versions up to 5.17-rc2)
Red Hat Enterprise Linux 8.x and related variants
Debian Linux 9.0, 10.0, and 11.0
Canonical Ubuntu Linux 14.04 ESM through 22.04 LTS
Fedora 35
NetApp SolidFire, HCI Storage and Management Nodes
Red Hat Virtualization Host 4.0

Discovery Timeline

March 3, 2022 - CVE-2022-0492 published to NVD
November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-0492

Vulnerability Analysis

The vulnerability resides in the cgroup_release_agent_write function within kernel/cgroup/cgroup-v1.c. The core issue is a missing authorization bypass check (CWE-862) combined with an improper authentication vulnerability (CWE-287) that allows an attacker to modify the release_agent file within cgroups v1 hierarchy.

The release_agent mechanism in cgroups v1 is designed to execute a userspace program when a cgroup becomes empty. Under normal circumstances, this functionality requires appropriate capabilities and should be restricted to prevent unprivileged users from specifying arbitrary executables. However, the vulnerable code path fails to properly verify that the caller possesses the necessary privileges to perform this operation, particularly when operating within user namespaces.

An attacker who can mount a cgroup filesystem (which may be possible within certain container configurations) can write a path to an arbitrary executable into the release_agent file. When the cgroup empties, the kernel executes this program with root privileges on the host, effectively bypassing container isolation.

Root Cause

The root cause is a missing capability check in the cgroup_release_agent_write function. The code does not properly validate whether the caller has CAP_SYS_ADMIN in the initial user namespace before allowing modification of the release_agent file. This oversight allows users with CAP_SYS_ADMIN in a non-initial user namespace (such as within an unprivileged container) to exploit this functionality.

The fix implemented in commit 24f6008564183aa120d07c03d9289519c2fe02af adds the missing check to ensure the caller has CAP_SYS_ADMIN in the init_user_ns before permitting the write operation.

Attack Vector

The exploitation requires local access to the system with low privileges. An attacker operating within a containerized environment must be able to mount a cgroups v1 filesystem. This is typically possible when:

The container runs with a user namespace but without additional cgroup restrictions
The sys_admin capability is granted within the container's user namespace
The cgroup v1 filesystem is accessible for mounting

Once these conditions are met, the attacker can:

Mount a cgroup v1 filesystem within the container
Create a new cgroup hierarchy
Write a malicious executable path to the release_agent file
Trigger the release agent execution by emptying the cgroup
The malicious code executes with root privileges on the host system

The attack mechanism exploits the kernel's trust in cgroup operations without properly validating namespace boundaries, allowing container escape and privilege escalation to the host system.

Detection Methods for CVE-2022-0492

Indicators of Compromise

Unexpected modifications to release_agent files within cgroup hierarchies
Suspicious cgroup mount operations from within container environments
Evidence of cgroup filesystem mounting in /proc/mounts from unprivileged processes
Execution of unexpected binaries triggered by the cgroup release mechanism

Detection Strategies

Monitor for cgroup mount operations using audit rules targeting the mount syscall with cgroup filesystem types
Implement file integrity monitoring on /sys/fs/cgroup/*/release_agent files
Alert on processes with unexpected capabilities attempting to manipulate cgroup configurations
Deploy runtime container security monitoring to detect container escape attempts

Monitoring Recommendations

Enable kernel auditing for cgroup-related operations and capability usage
Monitor container runtime logs for privilege escalation indicators
Implement Seccomp profiles that restrict mount syscall usage within containers
Deploy SentinelOne Singularity for real-time detection of container escape behaviors and privilege escalation attempts

How to Mitigate CVE-2022-0492

Immediate Actions Required

Apply kernel patches from your Linux distribution immediately
Audit container configurations to ensure unnecessary capabilities are not granted
Verify that unprivileged users cannot mount cgroup filesystems within containers
Consider migrating to cgroups v2 which includes improved security controls

Patch Information

The vulnerability is addressed in Kernel Git Commit #24f6008 which adds proper capability checking in the init_user_ns before allowing release_agent modifications. Distribution-specific patches are available through:

Workarounds

Drop the CAP_SYS_ADMIN capability from containers using --cap-drop=SYS_ADMIN
Use AppArmor or SELinux profiles to restrict cgroup filesystem mounting
Apply Seccomp filters to block unnecessary syscalls including mount with cgroup types
Enable user namespace isolation with proper capability restrictions

bash

# Docker container hardening example
# Run containers without SYS_ADMIN capability
docker run --cap-drop=SYS_ADMIN --security-opt=no-new-privileges:true \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  your-container-image

# Verify cgroup v1 release_agent file permissions
ls -la /sys/fs/cgroup/*/release_agent

# Check for unexpected cgroup mounts
grep cgroup /proc/mounts