← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2022-0492 · CWE-287 · Disclosed 2022-03-03

A vulnerability was found in the Linux kernel’s cgroup_release_agent_write in the kernel/cgroup/cgroup-v1

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a fire escape that only matters after the attacker is already inside the building

CVE-2022-0492 is a Linux kernel cgroups v1 release_agent authorization bug. If an attacker can run code locally and reach the right cgroup controls, they can point release_agent at a program of their choice and get it executed by the host kernel as root, which turns a container foothold into a host escape. Upstream affected ranges called out by NVD are broad: Linux kernels from 2.6.24 up to fixed releases 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6, and 5.17-rc3.

The vendor's HIGH 7.8 score is technically defensible for raw impact, but it overstates real fleet risk in hardened enterprise estates. This is not unauthenticated remote code execution; it is a post-initial-access privilege-escalation/container-escape chain that usually needs root inside a container plus weak runtime settings such as cgroups v1, disabled or ineffective seccomp/AppArmor/SELinux, or a privileged/unconfined pod. In other words: severe impact, narrow path.

"Dangerous in weak container setups, but this is mostly a post-compromise escape path, not a universal internet-scale fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get code execution in a container or local shell

The attacker first needs a foothold on the Linux host or inside a container on that host. In practice this comes from a webshell, compromised workload, stolen CI runner, or some other earlier-stage access; CVE-2022-0492 is not the initial entry point. Weaponized post-exploitation uses ordinary shell tooling rather than a special exploit framework.
Conditions required:
  • Local code execution on the target Linux system or inside a container
  • A vulnerable host kernel
Where this breaks in practice:
  • This prerequisite already implies the attacker has passed your external perimeter and landed code execution
  • If the vulnerable kernel is only present on a subset of worker nodes, the reachable population drops fast
Detection/coverage: Traditional network scanners will miss this. EDR or container runtime telemetry is needed because the first observable step is local process activity.
STEP 02

Create namespaces with unshare and mount cgroup v1

The common exploitation path uses unshare -UrmC to create user, mount, and cgroup namespaces, then mounts a v1 cgroup controller with mount -t cgroup. Public walkthroughs from Sysdig show this exact sequence. The goal is to reach a writable release_agent file from inside the attacker's execution context.
Conditions required:
  • cgroups v1 available on the host
  • The runtime allows unshare/new namespaces or otherwise permits equivalent setup
  • The container is running as root or has sufficient capability to manipulate the target files
Where this breaks in practice:
  • Default seccomp profiles often block unshare
  • Many modern estates are moving to cgroups v2, which removes this exact path
  • Rootless or non-root containers usually break the straightforward exploit chain
Detection/coverage: Falco-style rules can catch unshare, cgroup mounts, and writes involving release_agent. Scanner coverage is generally weak because exploitability depends on runtime policy, not just package version.
STEP 03

Bypass runtime hardening and write release_agent

The attacker writes a host-path payload into the cgroup v1 release_agent file and enables notify_on_release for a child cgroup. The upstream fix added a missing requirement for CAP_SYS_ADMIN in the initial user namespace when setting release_agent, closing the authorization gap. Before that fix, the kernel could be tricked into launching the chosen helper with full host privileges.
Conditions required:
  • Ability to mount and interact with the relevant cgroup v1 hierarchy
  • AppArmor/SELinux not blocking the mount/write path, or the workload is privileged/unconfined
  • A container runtime configuration that exposes enough host semantics for the host path trick
Where this breaks in practice:
  • SELinux on OpenShift blocks the escape path by default according to Red Hat's bug record
  • AppArmor and SELinux commonly stop the mount/write sequence even when the kernel itself is vulnerable
  • Privileged containers are already one bad decision away from breakout; this CVE is just one of several escape options there
Detection/coverage: Look for writes to /sys/fs/cgroup/**/release_agent, notify_on_release, unexpected cgroup mounts, and short-lived shells spawned around those writes.
STEP 04

Trigger host-side execution as root

Finally the attacker moves a process into the prepared child cgroup and exits it, triggering the configured release agent. That helper runs on the host as root, converting a contained compromise into full node compromise. At that point the blast radius is the worker or host, not just the container.
Conditions required:
  • Successfully written release_agent and notify_on_release
  • Ability to trigger cgroup release
Where this breaks in practice:
  • If earlier hardening steps block the path, this trigger never matters
  • The impact is node-local unless the attacker can laterally move using orchestration credentials, secrets, or mounted cloud metadata
Detection/coverage: Runtime detection is your best shot: unexpected helper execution from cgroup release, child shells writing into cgroup control files, or root processes spawned from unusual parentage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusTreat as known exploited because the prompt's upstream intel says KEV listed: YES. Public campaign detail is thin, so confidence on *who* is exploiting it is lower than confidence that exploitation has occurred.
Proof-of-concept availabilityPublic exploitation guidance is readily available: Sysdig published a step-by-step container escape walkthrough, and NVD references a Packet Storm write-up titled Docker cgroups Container Escape.
EPSS0.05238 from the prompt. That is useful threat signal, but once KEV/active exploitation enters the picture, EPSS stops being the deciding factor.
KEV status and datesKEV: Yes per prompt intel. Direct public-date confirmation was inconsistent in this browsing session, so rely on the upstream intel for status and do not overfit to the crawled dates.
CVSS vectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — that is a classic local privesc vector: easy once local execution exists, but it says nothing about how hard getting that initial foothold is.
Affected versionsNVD tracks vulnerable upstream Linux kernels from 2.6.24 through the unfixed branches, including versions before 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6, and 5.17-rc3.
Fixed versionsUpstream fix is commit 24f6008564183aa120d07c03d9289519c2fe02af, first noted in 5.17-rc3. Distro backports include Ubuntu 20.04: 5.4.0-105.119, 18.04: 4.15.0-173.182, 16.04: 4.4.0-222.255; Debian bullseye 5.10.103-1; Debian buster 4.19.232-1.
Scanning / exposure realityThere is no meaningful Shodan/Censys/GreyNoise internet-exposure view for this CVE because it is not directly network-reachable. The real exposure question is internal: *which nodes run vulnerable kernels and host privileged, root, or unconfined containers on cgroups v1?*
DisclosurePublic disclosure landed on 2022-03-03 in NVD; the oss-security post discussing the fix is dated 2022-02-04.
Researchers / reportingThe oss-security notice credits Yiqi Sun and Kevin Wang of Huawei Security Team for the work leading to the fix.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive factor is that exploitation usually requires post-compromise local execution plus a weak container runtime posture; that sharply narrows real-world reach compared with the vendor's raw-impact score. The KEV signal prevents this from dropping into backlog-only territory, but the attack path is still far from universal across hardened Linux fleets.

HIGH Technical impact once exploitation succeeds
HIGH Downgrade due to attacker-position and runtime-hardening friction
LOW Prompt-supplied KEV status dates, which were not cleanly corroborated in this session

Why this verdict

  • Requires local or in-container execution first — this is not an external entry bug; it presumes the attacker is already on the box or in a workload.
  • Usually needs root and unsafe runtime settings — practical exploitation commonly depends on root inside the container, cgroups v1, and weakened seccomp/AppArmor/SELinux or a privileged/unconfined pod.
  • Modern controls cut the reachable population — default seccomp, SELinux on OpenShift, AppArmor, and cgroups v2 all add real friction that breaks many public exploit chains.
  • KEV keeps it relevant — known exploitation evidence means defenders should not ignore it just because the path is narrow.

Why not higher?

If this were unauthenticated remote code execution on a ubiquitous edge service, it would be a very different conversation. But CVE-2022-0492 sits behind multiple compounding prerequisites: prior compromise, local execution, container/root context, and runtime misconfiguration. Those are exactly the kind of real-world brakes that should push severity down.

Why not lower?

The impact is still full host-root compromise when the path exists, and public exploitation guidance is mature. Also, KEV status means somebody has already found enough of these weak configurations in the wild to matter, so writing it off as harmless local noise would be too optimistic.

05 · Compensating Control

What to do — in priority order.

  1. Ban privileged and unconfined containers — Enforce admission controls so pods cannot run privileged, unconfined, or with dangerous capability sets unless explicitly approved. Because the prompt indicates KEV-listed exploitation, deploy this immediately, within hours on exposed clusters; it directly removes the easiest escape path.
  2. Enforce seccomp and LSM profiles — Require a non-unconfined seccomp profile and keep AppArmor or SELinux enforcing on worker nodes. Do this immediately, within hours where possible, because public exploit chains rely on namespace creation, cgroup mounts, or writes that these controls often block.
  3. Reduce or eliminate cgroups v1 usage — Move workloads and hosts to cgroups v2 where your platform supports it, or at minimum identify nodes still exposing vulnerable v1 controller behavior. This is a strong structural mitigation; start immediately, within hours for exposed clusters and complete as part of the permanent fix.
  4. Disable unprivileged user namespaces where operationally safe — If your platform does not require them, disabling unprivileged user namespaces can break common exploitation setups using unshare. Apply this immediately, within hours after compatibility testing, especially on multi-tenant container hosts.
What doesn't work
  • A WAF does nothing here; the exploit path is local kernel/runtime abuse after code execution already exists.
  • Internet perimeter scanning is the wrong control; this flaw is not directly fingerprintable from Shodan-style exposure data.
  • Patching container images only is insufficient because the vulnerable component is the host kernel, not the application image.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host, not from an auditor workstation. Invoke it as sudo bash ./check-cve-2022-0492.sh; root is recommended so the script can inspect mounts and distro metadata. The script is conservative: it returns PATCHED where it can positively confirm known Ubuntu fixes or clearly fixed upstream versions, VULNERABLE where it can positively place the host in a vulnerable range, and UNKNOWN when distro backports make a safe call impossible.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2022-0492.sh
# Purpose: conservative host-side check for CVE-2022-0492
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

status="UNKNOWN"
reason="Insufficient evidence to determine patch state safely"

krel="$(uname -r 2>/dev/null || true)"
kbase="${krel%%-*}"

os_id="unknown"
os_ver="unknown"
if [ -r /etc/os-release ]; then
  # shellcheck disable=SC1091
  . /etc/os-release
  os_id="${ID:-unknown}"
  os_ver="${VERSION_ID:-unknown}"
fi

have_cgv1="no"
if grep -Eq ' - cgroup ' /proc/self/mountinfo 2>/dev/null; then
  have_cgv1="yes"
fi

verlt() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

verge() {
  [ "$1" = "$2" ] || ! verlt "$1" "$2"
}

set_result() {
  status="$1"
  reason="$2"
}

check_ubuntu() {
  case "$os_ver" in
    22.04|24.04|24.10|25.04|25.10)
      set_result "PATCHED" "Ubuntu release marked not affected by Canonical"
      return
      ;;
    21.10)
      if verlt "$kbase" "5.13.0"; then
        set_result "UNKNOWN" "Unexpected Ubuntu 21.10 kernel string: $krel"
      elif verlt "$krel" "5.13.0-37.42"; then
        set_result "VULNERABLE" "Ubuntu 21.10 kernel predates Canonical fixed build 5.13.0-37.42"
      else
        set_result "PATCHED" "Ubuntu 21.10 kernel is at or above Canonical fixed build 5.13.0-37.42"
      fi
      return
      ;;
    20.04)
      if verlt "$krel" "5.4.0-105.119"; then
        set_result "VULNERABLE" "Ubuntu 20.04 kernel predates Canonical fixed build 5.4.0-105.119"
      else
        set_result "PATCHED" "Ubuntu 20.04 kernel is at or above Canonical fixed build 5.4.0-105.119"
      fi
      return
      ;;
    18.04)
      if verlt "$krel" "4.15.0-173.182"; then
        set_result "VULNERABLE" "Ubuntu 18.04 kernel predates Canonical fixed build 4.15.0-173.182"
      else
        set_result "PATCHED" "Ubuntu 18.04 kernel is at or above Canonical fixed build 4.15.0-173.182"
      fi
      return
      ;;
    16.04)
      if verlt "$krel" "4.4.0-222.255"; then
        set_result "VULNERABLE" "Ubuntu 16.04 kernel predates Canonical fixed build 4.4.0-222.255"
      else
        set_result "PATCHED" "Ubuntu 16.04 kernel is at or above Canonical fixed build 4.4.0-222.255"
      fi
      return
      ;;
  esac
}

check_generic_upstream() {
  # If the kernel release string has distro packaging suffixes, upstream-only checks are unreliable.
  if [ "$krel" != "$kbase" ] && printf '%s' "$krel" | grep -Eq '(generic|amd64|el[0-9]|uek|aws|azure|gcp|oracle|fc[0-9]|amzn)'; then
    set_result "UNKNOWN" "Distro/backport kernel detected ($krel); exact vendor advisory needed"
    return
  fi

  if verlt "$kbase" "4.9.301"; then
    if verge "$kbase" "2.6.24"; then
      set_result "VULNERABLE" "Kernel falls in an upstream vulnerable range before 4.9.301"
      return
    fi
  fi

  if verge "$kbase" "4.10" && verlt "$kbase" "4.14.266"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.10 to <4.14.266"
    return
  fi

  if verge "$kbase" "4.15" && verlt "$kbase" "4.19.229"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.15 to <4.19.229"
    return
  fi

  if verge "$kbase" "4.20" && verlt "$kbase" "5.4.177"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.20 to <5.4.177"
    return
  fi

  if verge "$kbase" "5.5" && verlt "$kbase" "5.10.97"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.5 to <5.10.97"
    return
  fi

  if verge "$kbase" "5.11" && verlt "$kbase" "5.15.20"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.11 to <5.15.20"
    return
  fi

  if verge "$kbase" "5.16" && verlt "$kbase" "5.16.6"; then
    set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.16 to <5.16.6"
    return
  fi

  if verge "$kbase" "5.17"; then
    set_result "PATCHED" "Kernel is newer than the affected upstream branches"
    return
  fi

  set_result "UNKNOWN" "Kernel version not safely classifiable with generic upstream logic"
}

if [ -z "$krel" ]; then
  echo "UNKNOWN - unable to read kernel release"
  exit 2
fi

if [ "$os_id" = "ubuntu" ]; then
  check_ubuntu
else
  check_generic_upstream
fi

# Add context about cgroup v1 exposure without changing patch verdict.
context="kernel=$krel os=$os_id/$os_ver cgroup_v1=$have_cgv1"

echo "$status - $reason ($context)"
case "$status" in
  PATCHED) exit 0 ;;
  VULNERABLE) exit 1 ;;
  *) exit 2 ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like an internet-exposed emergency on every Linux node; treat it like a focused hunt for weak container hosts. Find worker nodes still on vulnerable kernels, then cross that list with workloads running as root, privileged, unconfined, or on cgroups v1. Because the prompt indicates KEV-listed exploitation, override the usual MEDIUM posture and patch / mitigate immediately, within hours for exposed clusters and container hosts. For the broader fleet, this verdict carries noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, but KEV overrides that for exposed systems; the noisgate remediation SLA for a MEDIUM issue remains ≤365 days for the rest of the affected estate.

Sources

  1. NVD CVE-2022-0492
  2. oss-security disclosure
  3. Red Hat Bugzilla 2051505
  4. Ubuntu CVE page
  5. Debian DSA-5095-1
  6. Debian DSA-5096-1
  7. Sysdig exploitability analysis
  8. CISA KEV query reference
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.