How to Fix Dirty Pipe (CVE-2022-0847) on Linux Hosts

Dirty Pipe (CVE-2022-0847) is a Linux kernel flaw, present in upstream kernels from 5.8, that lets an unprivileged local user overwrite the cached contents of read-only files and escalate to root. Fix it by installing your distribution’s patched kernel (the advisory in the finding title, such as RHSA-2022:0820), rebooting into it, and confirming with uname -r.

What the scanner is actually detecting

Nessus does not report Dirty Pipe under its nickname. It appears inside distribution kernel plugins, each named after one vendor advisory, with CVE-2022-0847 as one entry in the plugin’s CVE list. These are local checks, so they only run in credentialed (SSH) scans. For all four plugins below, Tenable states that Nessus relied on the self-reported package version rather than testing the flaw.

These are roll-up findings. Plugin 158807, for example, lists CVE-2021-4083, CVE-2022-0330, CVE-2022-0492, CVE-2022-0847 and CVE-2022-22942, so one kernel update closes all five. Tenable keeps the full plugin list for CVE-2022-0847, which covers many more distributions and streams.

The bug itself: when the kernel creates a new pipe buffer in copy_page_to_iter_pipe() and push_pipe(), it does not initialize the buffer’s flags field, so a stale value can survive. Max Kellermann, who found it, showed that a user who splices a page of a readable file into a pipe can then write into that page in the page cache. He notes it works on immutable files and read-only mounts too, because writing to a pipe never checks file permissions.

Real-world risk

This is a local privilege escalation with a CVSS v3.1 base score of 7.8 (AV:L/AC:L/PR:L). The attacker needs to run code on the host and needs read access to the file they want to change. It is not reachable over the network by itself. The points that raise its priority:

• Kellermann describes it as similar to Dirty COW (CVE-2016-5195) but easier to exploit, and says it leads to privilege escalation because unprivileged processes can inject code into root processes.
• Public proof-of-concept exploit code has circulated since disclosure, and Tenable’s CVE page links to several examples.
• CISA added CVE-2022-0847 to the Known Exploited Vulnerabilities catalog on April 25, 2022, with a federal due date of May 16, 2022. See our CISA KEV catalog explainer for what that listing should mean for patch priority.

There are real limits. The write cannot cross a page boundary, cannot start on one, and cannot grow the file. Because the modified page is not marked dirty, the change normally is not written back to disk and is gone after a reboot, so the file on disk may not show what happened.

Exposure also depends on the vendor kernel. Red Hat states that the currently known exploits do not work on RHEL 8, because the PIPE_BUF_FLAG_CAN_MERGE attack vector is not available there, yet it still shipped fixes. SUSE says exploitation needs two bugs, one added in kernel 5.8, so SLES 15 SP3 and older are not affected by the problem, although it also released updated kernels. Ubuntu lists 18.04 LTS and the 20.04 LTS base kernel as not affected, and Debian lists buster (Debian 10) as not affected. Hosts running code you do not fully trust (shared shell servers, CI runners, container hosts) deserve the fastest reboot slot.

How to confirm it on the host

Start with the running kernel and the OS release. The running kernel is what matters, not the newest one installed:

uname -r
grep -E '^(NAME|VERSION_ID)=' /etc/os-release

On RHEL and Oracle Linux, list installed kernels and check whether the running build carries the fix. RHEL kernels keep the 4.18.0 base version, so check the changelog rather than the upstream number:

rpm -q kernel-core
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2022-0847

On Debian, uname -v prints the package version of the running kernel. On Ubuntu, /proc/version_signature does the same:

# Debian
uname -v
dpkg -l 'linux-image-*' | grep ^ii

# Ubuntu
cat /proc/version_signature
dpkg -l 'linux-image-*' | grep ^ii

On SLES and openSUSE, check the kernel package and ask zypper whether a patch for the CVE is still needed:

rpm -q kernel-default
zypper list-patches --cve=CVE-2022-0847

Red Hat also publishes a signed detection script in bulletin RHSB-2022-002. Do not run public exploit code on production hosts to test this.

How to fix it

There is no configuration workaround. Red Hat states that no mitigation is available, that SELinux does not mitigate the flaw, and that kpatch cannot mitigate it. The fix is a new kernel plus a reboot. Upstream, the fix landed in 5.16.11, 5.15.25 and 5.10.102. Distribution builds carry it under their own version numbers:

The advisory in a plugin title tells you which update stream Nessus matched, which is not always the stream you run. Install the fixed build for the stream the host is subscribed to. For real-time kernels, Red Hat lists RHSA-2022:0819 (RHEL 8), RHSA-2022:0822 (8.4 EUS) and RHSA-2022:0821 (8.2 EUS) for kernel-rt.

RHEL

# install the advisory named in the finding (example: RHEL 8.2 EUS host)
sudo yum update --advisory=RHSA-2022:0820

# or simply take the newest kernel in your stream
sudo yum update kernel

sudo reboot

Using --advisory also updates the other packages in the advisory that are installed, such as kernel-tools, perf and bpftool, which the plugin checks too.

Oracle Linux

sudo dnf update kernel
sudo reboot

ELSA-2022-0825 covers the Red Hat Compatible Kernel, not the Unbreakable Enterprise Kernel. If uname -r shows a UEK build, check Oracle’s UEK advisories for that kernel separately.

Ubuntu and Debian

sudo apt update
sudo apt full-upgrade
sudo reboot

Ubuntu notes that USN-5317-1 came with an unavoidable ABI change, so the kernel was given a new version number and any third-party kernel modules must be recompiled. The standard metapackages (linux-generic, linux-generic-hwe-20.04) pull in the new image automatically.

SLES and openSUSE

sudo zypper patch --cve=CVE-2022-0847
sudo reboot

Plain sudo zypper patch also works and applies every pending patch. SUSE’s CVE-2022-0847 page lists the fixed build for each service pack.

How to verify the fix and rescan

1. After the reboot, run uname -r and compare it with the table above. On RHEL, rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2022-0847 should return a line.
2. Check that no reboot is still pending. On RHEL 8, sudo dnf needs-restarting -r reports whether one is required. On Ubuntu and Debian, the file /var/run/reboot-required exists until the host restarts.
3. Rerun the credentialed Nessus scan. The plugin should no longer report the host. In the Nessus Scan Information output (plugin 19506), confirm that credentialed checks show yes; if the SSH login failed, the local plugins never run and the finding disappears for the wrong reason.

Installing the package without rebooting leaves the old kernel in memory. Whatever a report says, the host is protected only once uname -r shows the fixed build.

What can break and how to roll back

The risk is the reboot and the kernel change, not this specific fix. Watch for:

• Out-of-tree kernel modules (DKMS drivers, GPU drivers, storage or security agents with kernel components) that do not load against the new kernel.
• Services that do not start cleanly after an unplanned restart. Our guide to reboot orchestration for patching covers staging this across a fleet.

Package managers keep the previous kernel installed, so rollback means booting it. On RHEL and Oracle Linux, use grubby:

sudo grubby --info=ALL | grep ^kernel
sudo grubby --set-default /boot/vmlinuz-<previous-version>
sudo reboot

On Ubuntu, Debian and SUSE, choose the previous kernel from the GRUB “Advanced options” menu at boot. Booting the old kernel reopens CVE-2022-0847, so only stay on it while you fix what broke.

Common false positive reasons

• Backported fixes. RHEL, Oracle Linux and SUSE fix the bug without changing the base kernel version (4.18.0 or 5.3.18). A tool that compares only upstream versions will flag patched hosts. If the package matches the advisory build and the changelog lists CVE-2022-0847, the host is fixed. See why backported patches cause false positives for how to record this.
• Vendor says “not affected” but the plugin fires. On SLES 15 SP3 and older, and on RHEL 8, the vendor considers known exploitation unworkable, yet the package is below the fixed build. That is a real version finding with lower practical risk. Patch it rather than suppress it.
• Stale results. The scan predates the reboot, or the rescan ran without working credentials.
• Old kernel packages still installed. If the finding persists after a reboot into a fixed kernel, read the plugin output to see which package version it cites.

FAQ

Can Dirty Pipe be exploited remotely?

No. The attacker needs to run code on the host first, for example through a compromised application or a low-privileged account.

Do I need to reboot?

Yes. Red Hat’s advisories state that the system must be rebooted for the update to take effect, and Ubuntu’s notice says the same.

Can SELinux or live patching cover the gap?

Not on RHEL. Red Hat states that SELinux does not mitigate the flaw and kpatch cannot mitigate it. For other distributions, check your vendor’s live patch notes.

Why does a RHEL 8 host on kernel 4.18 get flagged?

Red Hat’s 4.18 kernel includes backported code containing the flaw. Red Hat says known exploits do not work on RHEL 8, but it shipped fixes and Nessus checks against them.

Tracking this finding across many hosts

With a kernel fix, the hard part is proving every host actually rebooted into the new build. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus findings. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Linux endpoints, and SITEY re-tests afterward to verify closure.

Sources

• Max Kellermann: The Dirty Pipe Vulnerability (CVE-2022-0847)
• Red Hat: RHSB-2022-002 Dirty Pipe, kernel arbitrary file manipulation (CVE-2022-0847)
• Red Hat: RHSA-2022:0820 kernel security update
• Ubuntu: USN-5317-1 Linux kernel vulnerabilities
• Tenable: Nessus plugin 158807, RHEL 8 : kernel (RHSA-2022:0820)