CVE-2022-0492: Linux Kernel Improper Authentication Vulnerability
Linux Kernel contains an improper authentication vulnerability which could allow for privilege escalation via the cgroups v1 release_agent feature.
Overview
The Linux kernel's cgroups v1 subsystem failed to require CAP_SYS_ADMIN in the initial user namespace before accepting writes to the release_agent control file. Because the kernel executes the release_agent path via call_usermodehelper with a full capability set, a low-privileged local user or a process running inside a container could write an arbitrary executable path and have it run as root, bypassing namespace isolation entirely. Affected kernels span from 2.6.24 through the 5.16 and 5.17-rc2 release lines, with fixed boundaries across multiple stable branches.
Vulnerability details
The flaw sits in cgroup_release_agent_write() and the mount-time cgroup1_parse_param() path in kernel/cgroup/cgroup-v1.c. Both code paths accepted writes to the release_agent file without verifying that the caller held CAP_SYS_ADMIN in the initial user namespace. The missing authorization check (CWE-862) meant that a process operating inside a non-initial user namespace, such as an unprivileged container, could set the release_agent path as if it were a privileged host process. The kernel then invokes that path through call_usermodehelper, which starts the helper with a full capability set regardless of who configured it.
An attacker with at least low-privilege local or container access writes an arbitrary executable path to the cgroups v1 release_agent file. When a cgroup becomes empty, the kernel invokes that path with full capabilities, executing the attacker's payload as root on the host. This path also breaks namespace isolation: a process confined to a container can reach outside its namespace boundary and execute code on the underlying host. The preconditions are that cgroups v1 must be available and mounted (the default on many Linux distributions) and the attacker must be able to write to the release_agent file from within a user namespace or unprivileged container context.
Severity and impact
Exploitation status
This vulnerability is confirmed as actively exploited in the wild — it is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Detection and monitoring
- Audit writes to cgroup release_agent files: look for auditd SYSCALL records where the path matches /sys/fs/cgroup/**/release_agent and the process UID is non-zero or the process is running inside a non-initial user namespace (audit field user_ns != 0).
- Monitor for new or modified release_agent file content via inotify or fanotify on /sys/fs/cgroup; any write from a process whose credentials do not include CAP_SYS_ADMIN in the initial user namespace is anomalous on patched systems and indicates exploitation on unpatched ones.
Remediation
Additional hardening
- Upgrade the Linux kernel: apply 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, or 5.16.6 for the respective stable branch, or 5.17-rc3 or later for the mainline; see the vendor advisory in References for distribution-specific packages.
- Disable or unmount cgroups v1 where not operationally required; systems running only cgroups v2 are not affected by this release_agent path.
- Restrict container runtimes so that user namespace creation by unprivileged processes is blocked: set kernel.unprivileged_userns_clone=0 (where supported) to remove the precondition that allows container-context exploitation.
- Apply a restrictive seccomp or LSM (AppArmor/SELinux) profile to container workloads that denies writes to cgroup control files, reducing the attack surface on hosts where cgroups v1 cannot be disabled.
Key dates
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2051505
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af
- https://www.kernel.org/
- https://nvd.nist.gov/vuln/detail/CVE-2022-0492
- http://packetstormsecurity.com/files/166444/Kernel-Live-Patch-Security-Notice-LSN-0085-1.html
- http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html
- http://packetstormsecurity.com/files/176099/Docker-cgroups-Container-Escape.html
- https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html
Frequently asked questions
Does CVE-2022-0492 affect my FedRAMP authorization?
If Linux Kernel runs inside your authorization boundary, yes. CVE-2022-0492 is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and its remediation deadline of June 5, 2026 has already passed. For a FedRAMP-authorized service, an unpatched KEV is an assessor finding. An overdue one is a finding your assessor and sponsoring agency can see right now. Your options are to remediate it or formally document the mitigation and the delay.
How does Knox help me handle CVE-2022-0492?
Knox does not patch your software. Remediating Linux Kernel is your responsibility under the FedRAMP shared-responsibility model. What Knox provides is the pre-authorized, single-tenant boundary to remediate within, along with Knox's automated continuous monitoring platform and audit-artifact coverage that document the fix for your next assessment. Applying the patch is yours to do. Managing your compliance posture while you do it is not something you have to handle on your own.
How does Knox's monitoring help with vulnerabilities like this?
Knox's automated continuous monitoring platform watches your environment continuously for newly disclosed vulnerabilities and compliance issues, including cases like CVE-2022-0492. Exposure surfaces during ongoing monitoring rather than only when an assessor flags it at review time, giving you the earliest possible opportunity to act.
How do I get FedRAMP authorized with Knox?
Knox runs a FedRAMP-as-a-Service platform. It gives SaaS vendors a pre-authorized cloud boundary on AWS, Azure, and GCP. Your application inherits 60-80% of the required security controls. You reach FedRAMP authorization in about 90 days for roughly 90% less than the traditional $3.5M path. Book a meeting and Knox will map your path to authorization.
CVE-2022-0492's remediation deadline of June 5, 2026 has passed. What happens now?
If CVE-2022-0492 remains unremediated, it is already a Plan of Action and Milestones (POA&M) item. A growing POA&M list is what turns a routine continuous-monitoring review into a difficult conversation with your agency. Closing it out now and documenting why the deadline was missed is what keeps your authorization clean and the agency relationship intact.
Ready to achieve FedRAMP authorization in 90 days or less?
Schedule a meeting to discuss scope, parse readiness, and map your company’s accelerated path to FedRAMP authorization.
_Horizontal_RGB.png)
