How To Fix CVE-2022-0492- Privilege Escalation And Container Escape Vulnerabilities In Cgroups

A new vulnerability has been spotted recently in the Linux Control group, a Linux kernel feature that allows processes to be organized into hierarchical groups. The vulnerability is tracked as CVE-2022-0492 is a High severity vulnerability with a CVSS score of 7.0. This vulnerability allows adversaries to escape containers and could perform arbitrary command execution on the host machine. Users of containers should know about this vulnerability and fix them up as soon as possible. We have created this post to help users to learn how to fix CVE-2022-0492- Privilege escalation and container escape vulnerabilities in Cgroup.

Before we dive into fixing the vulnerability, let’s understand some basics about Cgroups.

What Is Cgroups?

Control groups, referred to as cgroups, are a Linux kernel feature that allows organized processes into hierarchical groups. This feature made it a perfect building block of containers and allowed administrators to limit and isolate the resource usage of a collection of processes. Linux systems support two architectures of Cgroup, (1) v1 and (2) v2. The CVE-2022-0492 vulnerability exists in v1, which is the most prevalent architecture as of. 

What Is Cgroupfs?

Cgroup is a pseudo-filesystem used as an interface to manage Cgroups. It is mounted under /sys/fs/cgroup, which is the root directory of Cgroupfs. Cgroups are divided into several subsystems to manage different resources such as memory, CPU, block IO, remote direct memory access (RDMA). For example, memory subgroup mounted on /sys/fs/cgroup/memory is used to limit the memory consumption of a collection of processes, device subgroup mounted on /sys/fs/cgroup/device is used to defines which devices can be accessed by processes in the cgroup.

Each subsystems are mounted at /sys/fs/cgroup/<subsystem>. A directory under a subgroup is called child group. For example, a docker container mounted at at /sys/fs/cgroup/<subsystem>/docker/<ctr-id> is a child group of the subgroup. 

Summary Of CVE-2022-0492- Privilege Escalation And Container Escape Vulnerabilities In Cgroups:

As per the Unit 42, “At first glance, a privilege escalation vulnerability that can only be exploited by the root user may seem bizarre. In the past, this wouldn’t be considered a security issue. But today, running as root doesn’t necessarily mean full control over the machine: There’s a gray area between the root user and full privileges that include capabilities, namespaces, and containers. In these scenarios where a root process doesn’t have full control over the machine, CVE-2022-0492 becomes a serious vulnerability”.Unit 42- Palo Alto

Associated CVE IDCVE-2022-0492
DescriptionPrivilege Escalation and Container Escape Vulnerabilities in Cgroups
Associated ZDI ID
CVSS Score7.0 Medium
Impact Score
Exploitability Score
Attack Vector (AV)Low
Attack Complexity (AC)High
Privilege Required (PR)Low
User Interaction (UI)None
Confidentiality (C)High
Integrity (I)High
availability (a)High

Containers Vulnerable To CVE-2022-0492- Privilege Escalation And Container Escape Vulnerability In Cgroups:

The flaw doesn’t affect all the containers. The flaw can be exploited only in some circumstances.

  1. The container should have the v1 architecture of cgroups.
  2. Root privilege without the no_new_privs flag set.
  3. Container with disabled AppArmor or SELinux and without Seccomp features.
  4. On a host that enables unprivileged user namespaces.
See also  How Attackers Abuse The Dell BIOSConnect And HTTPS Boot Vulnerabilities To Compromise The Dell Computers?

See Also How To Fix CVE-2021-22205, Unauthenticated RCE Vulnerability In GitLab


  1. The container should have the v1 architecture of cgroups.
  2. The container with CAP_SYS_ADMIN capability enabled.
  3. Container with disabled AppArmor or SELinux and without Seccomp features.
  4. Container without cgroup namespaces.

How To Test Your Container Is Vulnerable to CVE-2022-0492?

Researchers from Palo Alto’s unit 42 team has developed a script to test whether your container is vulnerable to CVE-2022-0492. You should need to pull and run the pre-build image from public repository. The container will tell you as soon as you run the image.

# Run this command to pull the container image:
$ sudo docker pull

# Run this command to run the container image:
$ sudo docker run

Further checks to determine the container is vulnerable to CVE-2022-0492:

Run the container by tweaking the configurations of AppArmor or SELinux and Seccomp features.

$ sudo docker run --rm -it --cap-add sys_admin

$ sudo docker run --rm -it --cap-add sys_admin --security-opt apparmor=unconfined

$ sudo docker run --rm -it --security-opt apparmor=unconfined --security-opt seccomp=unconfined

In this scenario, we can clearly say that our container is vulnerable to the flaw. It is just protected by AppArmor or SELinux and Seccomp features.

How To Fix CVE-2022-0492- Privilege Escalation And Container Escape Vulnerabilities In Cgroups?

The flaw is patched in the latest version of the kernel. All are encouraged to upgrade to the latest kernel. Please contact your vendor or Linux distributions to get the latest versions.

In the previous session, we can say that the container is vulnerable to the flaw. It is just protected by AppArmor or SELinux and Seccomp features. Keep the AppArmor or SELinux and Seccomp features enabled until there is a permanent fix.

See also 

General mitigations are:

  1. Enable AppArmor or SELinux on Kubernetes.
  2. Enable Seccomp on Kubernetes.
  3. In a case of privilege escalation due to a malicious host process, you may need to disable unprivileged user namespaces using this command:
    $ sudo sysctl -w kernel.unprivileged_userns_clone=0
  4. Palo Alto developed a script to prevent processes from setting the release_agent in any cgroup mount. This script masks all release_agent files with a read-only bind mount. If your system mounts cgroups at a different path, provide the path as an argument to the script.
set -e
if [ ! -z "$1" ]; then cgroup_dir=$1 ; fi
echo "[+] Creating mask at $mask_dir/mask"
sudo mkdir -p $mask_dir
sudo mount -t tmpfs release_agent_mask $mask_dir
sudo touch $mask_dir/mask
sudo mount -o remount,ro $mask_dir
for release_agent in $(find $cgroup_dir -name 'release_agent') ;do 
    echo "[+] Mounting read-only mask over $release_agent"
    sudo mount --bind $mask_dir/mask $release_agent

How To Upgrade Kernel On Your Linux?

There are multiple ways to update the kernel on Linux. The best and the native way is to download and install the tested kernel package. Please contact your support to choose the best way that works for you. Just for the demonstration, we are going to show you how to upgrade the kernel on Ubuntu or Debian servers in a native way.

How to Fix CVE-2022-0492 on Ubuntu?

Note: Before you download and install on your production server, we recommend to test this on a test machine. Don’t forget to take the full VM snapshot if are upgrading kernel on a Virtual Image. Or, take filesystem back up if you have a physical server.

See Also How To Fix CVE-2022-26809- A Critical RCE Vulnerability In Windows RPC Runtime

  1. Check the kernel versionBefore you start upgradation, check the version of the kernel your server has. What if the kernel version is not in the list of affected versions, If so, you can schedule this later as per your time.

    Run this command to check the kernel version.

    $ uname -rs

    Check the kernel version
  2. Download kernel modules 5.17Download the kernel packages directly from the website. Download the latest version available (At the bottom) from the website to a dedicated directory. Change the permission of the files to execute.

    Create a directory in your path:

    $ mkdir /home/arunkl/kernel-5.17

    Change the directory:

    $ cd /home/arunkl/kernel-5.17/

    Download these two files (where X.Y.Z is the highest version):

    1. linux-image-*X.Y.Z*-generic-*.deb
    2. linux-modules-X.Y.Z*-generic-*.deb

    Commands to download the kernel v5.17

    $ wget

    $ wget

    Run this command to set the files permission to execution mode:

    $ chmod +x *.deb

    Download kernel modules 5.17
  3. Install kernel module 5.17Install the downloaded packages using the default dpkg utility then reboot the server.

    $ sudo dpkg –install *.deb
    $ reboot

    Install kernel module 5.17
  4. Check the kernel version after rebootUse the same command used in the first step. You will see upgraded kernel version if everything goes well.

    $ uname -rs

    Check the kernel version after reboot

Leave a Reply

Your email address will not be published. Required fields are marked *