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:

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

Once these conditions are met, the attacker can:

1. Mount a cgroup v1 filesystem within the container
2. Create a new cgroup hierarchy
3. Write a malicious executable path to the release_agent file
4. Trigger the release agent execution by emptying the cgroup
5. 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:

• Red Hat Bugzilla Report #2051505
• Debian Security Advisory DSA-5095
• Debian Security Advisory DSA-5096
• NetApp Security Advisory NTAP-20220419-0002

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

# 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