CVE-2022-0847

What it actually does

CVE-2022-0847, commonly known as Dirty Pipe, is a Linux kernel privilege-escalation flaw caused by uninitialized pipe buffer flags in kernel pipe handling routines. A local unprivileged user can abuse stale pipe buffer state to write arbitrary data into the page cache for files that should be read-only. Because the write occurs through the page cache rather than normal file permissions, an attacker can temporarily alter the in-memory contents of privileged files or executables, potentially modifying authentication data, injecting code into root-owned binaries, or altering configuration read by privileged processes. Successful exploitation typically results in local root privileges with high confidentiality, integrity, and availability impact.

Why it matters to the business

A user or compromised low-privilege process on an affected Linux host can become root, allowing full system takeover, disabling security controls, stealing secrets, modifying applications, deploying persistence, or staging ransomware and lateral movement. This issue is known to be exploited in the wild, is listed in CISA KEV with a remediation deadline of 2022-05-16, and has a high EPSS score, so unpatched systems should be treated as high-priority exposure. The supplied affected-product metadata references a WordPress development repository, but the described vulnerability is in the Linux kernel; the operational risk applies to underlying Linux-based servers, containers, virtual machines, appliances, and Android-derived systems running vulnerable kernels.

How an attack unfolds

An attacker first needs local code execution as any unprivileged user, which may come from SSH access, a compromised web application, a container escape chain component, malware already running on the host, or another foothold. The attacker then runs a Dirty Pipe exploit that prepares a pipe, manipulates pipe buffer state, and triggers a splice/write sequence so the kernel treats a page-cache-backed read-only file as writable. The exploit commonly targets files or binaries that influence privilege boundaries, such as authentication files, SUID-root programs, or root-executed scripts. By changing the in-memory view of one of those files, the attacker can create a temporary root credential, cause a privileged binary to execute attacker-controlled code, or spawn a root shell. After gaining root, the attacker may clean up temporary artifacts, restore overwritten bytes, disable logging, add persistence, dump credentials, tamper with containers or host workloads, and move laterally.

How to fix it

Upgrade the Linux kernel to a vendor-fixed version immediately. Upstream fixes were released for affected kernel branches, including 5.16.11, 5.15.25, and 5.10.102; use the fixed package version provided by the operating system or appliance vendor rather than manually applying an upstream version unless that is the supported path. Reboot systems after installing the kernel update so the patched kernel is actually running. For Android or embedded Linux products, apply the vendor firmware or security update that includes the Dirty Pipe fix. If immediate patching is not possible, reduce risk by removing unnecessary local users, restricting shell access, limiting ability to upload or execute files, enforcing least privilege for service accounts, hardening container boundaries, monitoring for local exploit execution, and isolating high-risk systems. The supplied WordPress commit reference should not be treated as sufficient remediation for this kernel flaw; remediation must address the vulnerable Linux kernel on the host or device.

How to confirm the fix worked

Confirm exposure by checking the running kernel version, not only installed packages. On Linux, use commands such as `uname -r`, `cat /proc/version`, and the distribution package manager to verify the active kernel is at or above the vendor-fixed release. Confirm that systems were rebooted after patching; a patched kernel package installed on disk does not protect the system until the fixed kernel is running. Validate against vendor advisories for the specific distribution, cloud image, appliance, container host, or Android build. Where feasible, use authenticated vulnerability scanning or configuration management inventory to identify kernels in the vulnerable 5.8 and later affected ranges prior to fixed releases. Do not run public exploit code on production systems as a validation method unless it is part of an approved, controlled security test.

Typical attack path

1. Obtain local unprivileged execution on a Linux system through valid credentials, a compromised service, malware, or another vulnerability.
2. Check kernel version and architecture to determine whether the Dirty Pipe exploit path is viable.
3. Compile, upload, or execute a prebuilt CVE-2022-0847 exploit binary or script.
4. Use pipe buffer manipulation to write controlled data into the page cache of a read-only root-owned file or privileged executable.
5. Abuse the modified in-memory file contents to create a root shell, alter authentication behavior, or execute code through a privileged process.
6. Restore or mask modified content where possible to reduce visible evidence.
7. Use root access to establish persistence, access sensitive data, disable defenses, pivot to other systems, or deploy additional payloads.

How to detect it

Dirty Pipe exploitation is local and may not produce network indicators. Focus detection on endpoint telemetry, audit logs, shell history, EDR process events, file integrity monitoring, package inventory, and authentication logs. Look for low-privilege users compiling or executing exploit code, unexpected root shells, suspicious writes or attempted writes involving `/etc/passwd`, `/etc/shadow`, SUID binaries, or root-owned executables, and temporary files that resemble exploit tooling. Review auditd events for execution from `/tmp`, `/var/tmp`, `/dev/shm`, or user-writable directories followed by privilege changes to UID 0. Examine process lineage for web servers, application runtimes, CI runners, container processes, or non-admin user sessions spawning shells as root. Check for newly added users with UID 0, changed SUID bits, unexpected modifications to authentication files, altered privileged binaries, anomalous `su` or `sudo` behavior, and persistence created shortly after suspicious local execution. Because some Dirty Pipe techniques modify page cache contents temporarily and may restore files afterward, absence of file changes does not rule out exploitation; prioritize volatile evidence, EDR timelines, command history, and audit records. Threat reporting and exploit-trend references indicate ongoing exploitation interest across Linux and Android kernel privilege-escalation activity, so historical hunting should cover the full period since publication and any known compromise window.

• CVE-2022-0847
• Dirty Pipe
• DirtyPipe
• dirtypipe
• dirty_pipe
• blasty-vs-dirtypipe
• /tmp/dirtypipe
• /tmp/dirty_pipe
• /tmp/rootshell
• /tmp/rootsh
• /tmp/sh
• /var/tmp/dirtypipe
• /dev/shm/dirtypipe
• copy_page_to_iter_pipe
• push_pipe
• pipe_buffer
• /etc/passwd
• /etc/shadow
• /usr/bin/su
• /bin/su
• /usr/bin/sudo
• chmod u+s /tmp/sh
• chmod 4755 /tmp/sh
• uid=0(root) euid=0(root)

What your security team should do

• Prioritize patching or replacing all affected Linux kernels because the vulnerability is KEV-listed, actively exploited, and has a high EPSS likelihood.
• Inventory externally exposed servers, shared Linux hosts, container hosts, CI/CD runners, developer workstations, appliances, and Android-derived devices for vulnerable kernel versions.
• Verify that patched systems have been rebooted into the fixed kernel, and track exceptions until closed.
• Treat any host with suspicious local privilege-escalation activity as potentially fully compromised; collect forensic evidence before remediation where incident response is required.
• Review systems that allowed unprivileged shell, web-service, or container execution during the exposure window for signs of root escalation and persistence.
• Restrict local code execution paths, temporary directory execution, compiler availability, and unnecessary user access on systems awaiting patching.
• Deploy audit or EDR detections for suspicious writes or access to privileged files, unexpected SUID-root shell creation, exploit compilation, and anomalous root shells spawned by low-privilege users.
• Do not rely on application-level updates, including WordPress repository changes, to remediate this issue; ensure the operating system kernel itself is fixed.