CVE-2022-0492

What it actually does

This flaw is a Linux kernel authorization bypass in the cgroup v1 release_agent handling path. Under vulnerable conditions, a local attacker who can interact with a writable cgroup v1 hierarchy, commonly from a privileged or overly permissive container, can set a malicious release_agent path and trigger cgroup cleanup so the kernel executes attacker-controlled code with host-level root privileges. The result is privilege escalation, container or namespace isolation bypass, and potential full compromise of the underlying host. The upstream Linux kernel fix is commit 24f6008564183aa120d07c03d9289519c2fe02af.

Why it matters to the business

Successful exploitation can turn limited local or container-level access into root control of the host, allowing data theft, service disruption, tampering with workloads, deployment of persistence, and lateral movement across co-located applications. This is listed in CISA KEV with active exploitation observed in the wild and a remediation due date of 2026-06-05, so affected Linux systems and container platforms should be treated as high-priority even though the issue is older and not specifically marked as ransomware-used.

How an attack unfolds

An attacker first obtains local code execution on a Linux system or inside a container with enough privileges to mount or write to a cgroup v1 hierarchy. They create or reuse a cgroup, enable notify_on_release, and write a host-visible executable or script path into the cgroup release_agent file. They then move a process into the cgroup and cause the cgroup to become empty. On a vulnerable kernel, the release_agent mechanism runs the configured path with elevated host privileges, allowing the attacker to execute commands as root outside the intended namespace boundary. In containerized environments, the common impact is a container escape into the host operating system followed by credential access, persistence, tampering with container runtime state, or lateral movement.

How to fix it

Apply a vendor-supported kernel update that includes the upstream fix 24f6008564183aa120d07c03d9289519c2fe02af or the equivalent distribution backport. Reboot systems after kernel updates to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by disabling or avoiding cgroup v1 where feasible, using cgroup v2, preventing untrusted workloads from running privileged containers, removing CAP_SYS_ADMIN and other unnecessary Linux capabilities, blocking container access to host /sys/fs/cgroup, enforcing read-only cgroup mounts, disabling unprivileged user namespaces where operationally acceptable, and applying seccomp/AppArmor/SELinux profiles that prevent cgroup mounting and dangerous filesystem writes. Container platforms should be configured to prohibit privileged pods/containers, hostPID/hostIPC/hostNetwork access unless strictly required, and hostPath mounts to sensitive host locations.

How to confirm the fix worked

Confirm the running kernel is a fixed vendor build, not merely that a package is installed; compare uname -a and distribution package metadata after reboot. Validate that the kernel source or vendor advisory includes the equivalent of upstream commit 24f6008564183aa120d07c03d9289519c2fe02af. Check whether cgroup v1 is mounted with mount, findmnt, or /proc/filesystems, and identify writable release_agent files under /sys/fs/cgroup. In container environments, test policy enforcement by verifying ordinary workloads cannot run privileged, cannot mount cgroup filesystems, do not have CAP_SYS_ADMIN, and cannot write to /sys/fs/cgroup/*/release_agent. For exposure assessment, enumerate hosts running older kernels and containers/pods with privileged mode, hostPath mounts, or expanded Linux capabilities.

Typical attack path

1. Gain local shell access on a Linux host or command execution inside a container.
2. Confirm cgroup v1 is available and that cgroup files are writable or mountable from the current context.
3. Create or mount a cgroup v1 hierarchy and create a child cgroup.
4. Write 1 to notify_on_release for the attacker-controlled cgroup.
5. Write a host-resolvable payload path to the release_agent file.
6. Place a payload script or binary at the referenced path, often using /proc/self/mountinfo to identify host-visible paths from a container.
7. Move a process into the cgroup through cgroup.procs and terminate it so the cgroup becomes empty.
8. The kernel invokes the configured release_agent as host root, giving the attacker elevated command execution.
9. Use root access to persist, access secrets, manipulate workloads, disable defenses, or move laterally.

How to detect it

To determine whether exploitation already occurred, review kernel audit logs, auditd records, EDR telemetry, container runtime logs, Kubernetes audit logs, shell history, process execution logs, and file integrity monitoring for writes to cgroup v1 release_agent and notify_on_release files. High-signal events include a containerized process mounting a cgroup filesystem, writing to /sys/fs/cgroup/*/release_agent, writing 1 to notify_on_release, parsing /proc/self/mountinfo to discover host paths, creating payloads in temporary or shared paths, and then obtaining host-root execution. Audit for mount syscalls involving cgroup from containers, process executions whose parent context is unexpected or kernel-triggered, and suspicious scripts launched shortly after cgroup.procs changes. On Kubernetes or container platforms, correlate privileged pod/container creation, CAP_SYS_ADMIN grants, hostPath mounts, or writable /sys/fs/cgroup mounts with subsequent host-level commands. Because exploitation yields root, also hunt for post-exploitation artifacts such as new SSH authorized_keys entries, new systemd services, cron jobs, modified container runtime sockets, unexpected binaries in /tmp or /dev/shm, and credential or secret access after the suspected cgroup activity.

• release_agent
• notify_on_release
• /sys/fs/cgroup
• /sys/fs/cgroup/*/release_agent
• /sys/fs/cgroup/*/notify_on_release
• /sys/fs/cgroup/*/cgroup.procs
• /proc/self/mountinfo
• mount -t cgroup
• -t cgroup
• cgroup.procs
• echo 1 > notify_on_release
• echo 1 > /sys/fs/cgroup
• /tmp/cgrp
• /tmp/cgroup
• /dev/shm/cgrp
• /dev/shm/cgroup
• CAP_SYS_ADMIN
• privileged=true
• securityContext.privileged: true
• hostPath
• /var/run/docker.sock
• /run/containerd/containerd.sock
• /etc/cron.d
• /etc/systemd/system
• authorized_keys

What your security team should do

• Prioritize patching internet-facing, multi-tenant, container-hosting, CI/CD runner, Kubernetes node, and developer workstation systems that run Linux kernels without the cgroup release_agent fix.
• Meet or beat the CISA KEV remediation deadline of 2026-06-05 for in-scope systems, and track exceptions with compensating controls.
• Reboot after kernel updates and verify the running kernel version; do not rely only on package inventory.
• Hunt for historical writes to cgroup release_agent and notify_on_release files, especially from containerized processes or non-standard shells.
• Identify and reduce privileged containers, containers with CAP_SYS_ADMIN, writable /sys/fs/cgroup mounts, and hostPath mounts to sensitive host directories.
• Prefer cgroup v2 and disable cgroup v1 where application compatibility allows.
• Deploy runtime controls such as auditd, eBPF-based container runtime detection, SELinux/AppArmor, and seccomp profiles to detect or block cgroup mount/write behavior.
• Review hosts with evidence of exploitation for root-level persistence, modified startup files, added SSH keys, suspicious cron/systemd units, altered container runtime state, and credential access.