osbytes

Search

Find posts, projects, and members.

← back to blog

CVE-2022-0492 joins CISA KEV: cgroups v1 release_agent still escapes containers

2026-06-02by@osbytes6 min read
#linux #kernel #security #cve #cisa-kev #containers #coordinated-disclosure

TL;DR

  • CISA's KEV JSON feed picked up CVE-2022-0492 today (dateAdded 2026-06-02, dueDate 2026-06-05). The short description points at privilege escalation through cgroups v1 release_agent.
  • The kernel fix is commit 24f600856418 (merged for 5.17-rc3, February 2022): writing release_agent now requires CAP_SYS_ADMIN in the initial user namespace.
  • If your fleet still runs a pre-5.17 kernel (or a vendor tree without the backport), treat the KEV row as proof someone is exploiting this class in the wild, not as a fresh disclosure.

Why a four-year-old CVE landed on KEV today

CVE-2022-0492 is not new science. Red Hat filed it in March 2022 after researchers showed that cgroups v1 could be abused for container escape: mount cgroupfs inside an unprivileged user namespace, point release_agent at a binary you control, flip notify_on_release, kill the cgroup's last process, and the kernel runs your helper as root with a full capability set via call_usermodehelper.

What changed today is operator evidence. CISA only adds catalog entries when it believes exploitation is happening against the federal enterprise or the broader ecosystem. NVD's change history mirrors the same 2026-06-02 KEV metadata. The patch date is 2022; the action date is now.

That pattern should feel familiar if you read yesterday's note on WebLogic CVE-2024-21182 joining KEV: old CVE, new catalog pressure, short federal deadline.

The mechanism (why "improper authentication" is the right label)

In cgroups v1, release_agent is a root-owned path the kernel reads when a cgroup empties and notify_on_release is enabled. The helper is spawned through call_usermodehelper, which historically ran with all capabilities even if the writer was an unprivileged user who could create user namespaces and mount cgroup hierarchies.

Before the fix, cgroup_release_agent_write() in kernel/cgroup/cgroup-v1.c did not check that the writer was privileged enough to point root's helper at arbitrary paths. An attacker inside a container (or any environment with unprivileged user namespaces and cgroup mounts allowed) could:

  1. Create a cgroup under their control.
  2. Write release_agent to something like /tmp/payload (or a path visible from the host mount namespace, depending on layout).
  3. Enable notify_on_release.
  4. Exit the cgroup's processes so the kernel fires the agent.

Sysdig's 2022 walkthrough of the same bug class is still the clearest diagram of the namespace-staging trick if you want a second voice on the escape path (Sysdig on CVE-2022-0492).

Eric Biederman's fix is blunt: if you are not in init_user_ns with CAP_SYS_ADMIN, you cannot set release_agent at all, including through the cgroup1 mount parameter parser.

	/*
	 * Release agent gets called with all capabilities,
	 * require capabilities to set release agent.
	 */
	if ((of->file->f_cred->user_ns != &init_user_ns) ||
	    !capable(CAP_SYS_ADMIN))
		return -EPERM;

That closes the "unprivileged user in a nested namespace configures root's helper" hole. It does not magically upgrade every long-term-support kernel still on a 5.10/5.15 vendor branch that never cherry-picked the hunk.

What to check on hosts you actually run

Work from inventory, not vibes:

  • Kernel version floor: anything before 5.17 without a vendor backport is in the vulnerable class described in NVD's affected CPE ranges. Enterprise distros often backported the commit; verify the package changelog, not only uname -r.
  • User namespaces: if kernel.unprivileged_userns_clone / user.max_user_namespaces still allow unprivileged namespaces on multi-tenant nodes, you have the staging ground this exploit chain needs. Locking namespaces is a coarse but effective brake while you wait on kernel RPMs.
  • cgroups v1 vs v2: many container runtimes default to cgroup v2 now, which does not expose the same release_agent knob. Mixed hosts (legacy orchestrators, certain CI VMs, old Docker setups) may still mount cgroup v1 hierarchies; those are the ones worth grepping.
  • Managed Kubernetes: control-plane nodes and worker AMIs age out slowly. A KEV row on a kernel CVE is the prompt to ask your cloud vendor whether the node image you pinned six months ago includes 2022 cgroup hardening.

Federal teams owe mitigations by 2026-06-05 per the catalog row. Everyone else should still treat "known exploited" as a prioritization signal ahead of the next image bake.

Sources