CVE-2022-0185

What it actually does

This flaw is a heap-based buffer overflow in the Linux kernel Filesystem Context implementation, specifically in legacy_parse_param parameter length handling for filesystems that fall back to legacy parsing. A local attacker can pass oversized filesystem configuration parameters through the fsopen/fsconfig interface, corrupt adjacent kernel heap memory, and use that corruption to alter kernel execution or credential structures. When unprivileged user namespaces are enabled, exploitation can be performed by an unprivileged local user with no prior privileges; otherwise the attacker generally needs CAP_SYS_ADMIN inside a namespace. Successful exploitation results in local privilege escalation to kernel-level control, enabling full confidentiality, integrity, and availability compromise of the affected system.

Why it matters to the business

An attacker who already has a low-privileged shell, compromised service account, or container foothold can turn that access into full control of the Linux host. This can lead to data theft, disabling security tools, persistence, lateral movement, container or workload compromise, and operational disruption. The issue is listed in CISA KEV with a remediation due date of 2024-09-11 and has active in-the-wild exploitation, so it should be treated as a priority kernel exposure even though it requires local code execution. Systems that allow unprivileged user namespaces, shared hosting, CI/CD runners, container platforms, developer workstations, and multi-user Linux servers are higher risk.

How an attack unfolds

An attacker first obtains the ability to execute code locally, such as through stolen credentials, a compromised application, a malicious job, or access to a container or restricted shell. If unprivileged user namespaces are enabled, the attacker creates a new user namespace to gain namespace-scoped administrative capabilities; otherwise they need a context with namespaced CAP_SYS_ADMIN. The attacker then invokes the Linux filesystem context syscalls, typically fsopen and repeated fsconfig calls, against a filesystem path that triggers legacy parameter handling. By supplying an overly long parameter, they trigger the heap overflow in legacy_parse_param. A reliable exploit shapes kernel heap allocations so the overflow corrupts controlled kernel objects, then pivots that corruption into modifying credentials, bypassing namespace boundaries, or executing kernel-mode logic. Once successful, the attacker obtains root-level privileges on the host, disables defenses, installs persistence, collects secrets, and may move laterally or tamper with workloads.

How to fix it

Upgrade the Linux kernel to a vendor-supported build that includes the upstream fix, commit 722d94847de2, or the appropriate distribution backport. Because this is a kernel vulnerability, ensure the patched kernel is actually booted by rebooting affected systems or applying an approved live patch where available. Do not rely only on source commit presence unless using a self-built kernel; for packaged distributions, use the vendor advisory and package changelog to confirm the backport. As compensating controls, disable unprivileged user namespaces where business workloads permit, for example by setting kernel.unprivileged_userns_clone=0 on distributions that support it or reducing user.max_user_namespaces. Restrict CAP_SYS_ADMIN in containers and service sandboxes, avoid privileged containers, and apply seccomp or runtime policies that block rarely needed filesystem context syscalls such as fsopen, fsconfig, fsmount, move_mount, and open_tree where compatible. Limit local shell access, harden CI/CD runners and shared build hosts, and prioritize patching internet-facing systems that may provide attackers with an initial application-level foothold.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. Use uname -r and the distribution package manager to verify that the booted kernel version maps to a vendor release containing the CVE-2022-0185 fix or the upstream commit 722d94847de2 backport. Check whether a reboot is pending after kernel updates. On source-built kernels, verify that the relevant fs_context legacy_parse_param bounds-checking patch is present. Validate exposure reduction by checking user namespace settings such as /proc/sys/kernel/unprivileged_userns_clone where present and /proc/sys/user/max_user_namespaces. For container and sandboxed workloads, confirm runtime profiles do not grant unnecessary CAP_SYS_ADMIN and, where feasible, deny fsopen/fsconfig-related syscalls. If using vulnerability scanners or endpoint agents, ensure they inspect the running kernel version and vendor backport metadata rather than relying solely on upstream version comparison.

Typical attack path

1. Gain local code execution through a compromised account, vulnerable application, scheduled job, container workload, or interactive shell.
2. Check whether user namespaces are enabled or whether the current namespace grants CAP_SYS_ADMIN.
3. Create or enter a user namespace if unprivileged user namespaces are available.
4. Use fsopen and fsconfig against a filesystem path that falls back to legacy filesystem context parsing.
5. Send an oversized filesystem parameter to trigger heap corruption in legacy_parse_param.
6. Shape kernel heap state to convert the overflow into credential modification or controlled kernel execution.
7. Spawn a root shell or otherwise obtain host-level administrative privileges.
8. Disable logging or endpoint controls, dump credentials and secrets, establish persistence, and use the host for lateral movement.

How to detect it

Post-exploitation detection is more reliable than detecting the overflow itself, because exploitation occurs locally through kernel syscalls and may leave limited application-layer evidence. Review auditd, EDR, Sysmon for Linux, shell history, process accounting, container runtime logs, Kubernetes audit logs, and kernel logs. Look for unusual creation of user namespaces followed by filesystem context or mount-related activity, especially from low-privileged accounts, service users, web server processes, build agents, or containers. Audit records involving unshare, clone/clone3 with CLONE_NEWUSER or CLONE_NEWNS, and fsopen/fsconfig syscalls are high-value signals. Kernel logs may show crashes, oopses, slab corruption, general protection faults, or references to legacy_parse_param, fsconfig, or fs_context. Investigate unexpected root shells, new setuid-root binaries, modifications to /etc/sudoers or /etc/passwd, newly created root-owned files in writable directories, disabled security services, or unusual container escape indicators. Because the vulnerability has been exploited in the wild, correlate any suspicious local privilege escalation activity with the patch timeline and confirm whether the system was running a vulnerable kernel at the time of the event.

• legacy_parse_param
• fsconfig
• fsopen
• fs_context
• FSCONFIG_SET_STRING
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at fs/fs_context.c
• slab-out-of-bounds
• usercopy: kernel memory exposure attempt
• unshare -U
• unshare --user
• CLONE_NEWUSER
• CLONE_NEWNS
• /proc/sys/kernel/unprivileged_userns_clone
• /proc/sys/user/max_user_namespaces
• /etc/sudoers
• /etc/passwd
• /etc/ld.so.preload
• /tmp/sh
• /tmp/rootsh
• /dev/shm/exploit
• /var/log/audit/audit.log
• SYSCALL=fsopen
• SYSCALL=fsconfig
• comm="unshare"
• cap_sys_admin

What your security team should do

• Prioritize patching all affected Linux kernels because the vulnerability is in CISA KEV, has active in-the-wild exploitation, and enables local privilege escalation to full host control.
• Identify high-risk systems first: container hosts, Kubernetes nodes, shared Linux servers, CI/CD runners, developer workstations, VDI hosts, and any system where unprivileged user namespaces are enabled.
• Reboot systems after kernel updates or verify that an approved live patch is active; track systems with patched packages but still-running vulnerable kernels as unresolved.
• Temporarily disable unprivileged user namespaces where operationally acceptable and document exceptions for workloads that require them.
• Remove CAP_SYS_ADMIN and privileged container settings wherever possible; review container runtime, Kubernetes securityContext, and systemd sandboxing profiles.
• Deploy audit or EDR detections for suspicious user namespace creation followed by fsopen/fsconfig activity, especially by service accounts, web server users, build users, or containerized processes.
• Hunt historical telemetry for kernel crashes, privilege escalation artifacts, unexpected root shells, suspicious setuid file creation, and unusual namespace or mount activity.
• Treat successful exploitation as a full host compromise: collect forensic evidence, rotate credentials and secrets accessible from the host, rebuild from trusted images where necessary, and investigate lateral movement.