RHSB-2022-002 Dirty Pipe - kernel arbitrary file manipulation - (CVE-2022-0847)

Public Date: March 7, 2022, 12:00 pm
Updated -
Resolved Status
Important Impact

Insights vulnerability analysis

View exposed systems

Red Hat is aware of a vulnerability affecting the Linux kernel that allows an attacker to modify the contents of a file (either in memory or on disk) even when on read-only access mode.

This vulnerability is assigned CVE-2022-0847 and is also known as the Dirty Pipe vulnerability. This issue was publicly disclosed on March 7, 2022, and rated with a severity impact of Important.

Note that for Red Hat Enterprise Linux 8 (RHEL), the currently known exploits do not work. However, the underlying flaw is still present and other novel ways leading to successful exploitation cannot be fully ruled out.

The following Red Hat products are affected:

  • Red Hat Enterprise Linux 8

  • Red Hat Enterprise Virtualization 4

Further, any Red Hat product based on Red Hat Enterprise Linux 8 (including RHEL CoreOS) are also affected but not vulnerable as well. This includes products that pull packages from the RHEL channel, such as Red Hat OpenShift Container Platform 3, Red Hat OpenStack Platform and others. Please ensure that the underlying RHEL kernel package is current in these product environments.

To determine if your system is affected by this flaw, see the Diagnose section below.

A flaw was found in the way the "flags" member of the new pipe buffer structure lacked proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read-only files and, as such, escalate their privileges on the system.

This was demonstrated by creating new pipe buffers with the PIPE_BUF_FLAG_CAN_MERGE flag incorrectly set due to the lack of proper initialization. This flag controls coalescing of writes into a pipe buffer and thus allows for writing to an existing page spliced into the pipe. If a file backs this spliced page, the change will be reflected to the shared system-wide view of the file in memory and any subsequent cache flush will write the manipulated data to disk ignoring existing Linux permissions settings.

This would allow for an unprivileged user to overwrite specific contents of a file (either in memory or on disk) even when only allowed read-only access by existing access controls such as SELinux, standard Linux permissions, advanced access control, immutable files and devices being mounted ‘read only’.

Note that the PIPE_BUF_FLAG_CAN_MERGE flag attack vector is not available in Red Hat Enterprise Linux 8, thus the currently known exploits leveraging this flag do not work.

Refer to CVE-2022-0847 for more details.

Currently, there is no mitigation available for this flaw. SELinux does not mitigate this flaw. Kpatch is unable to mitigate this flaw. Customers should update to fixed packages once they are available.

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as errata are available. Customers are urged to apply the available updates immediately and enable the mitigations as they deem appropriate.



Advisory/Update [1]

Red Hat Enterprise Linux 8



Red Hat Enterprise Linux 8



Red Hat Enterprise Linux 8.4 Extended Update Support [2]kernelRHSA-2022:0831
Red Hat Enterprise Linux 8.4 Extended Update Support [2]kernel-rtRHSA-2022:0822
Red Hat Enterprise Linux 8.2 Extended Update Support [2]kernelRHSA-2022:0820
Red Hat Enterprise Linux 8.2 Extended Update Support [2]kernel-rtRHSA-2022:0821
Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions [3]kernelRHSA-2022:0823

Red Hat Virtualization 4



[1] Advisory/Update link will be added once updates are live.

[2] What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

[3] What is the Red Hat Enterprise Linux SAP Solutions subscription?

A vulnerability detection script has been developed to determine if your system is currently affected by this flaw. To verify the authenticity of the script, you can download the detached OpenPGP signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.

Current version: 1.1

Q: How can this flaw modify read-only content?
A: When a file is accessed, it gets loaded in the “cached” region of the memory (the page cache), and the attacker would be able to change the file content in the cached memory. So subsequent reads of the file will return the corrupted content.

Q: Can this flaw corrupt the content of actual files on disk?
A: It can. If a given content is in the “Dirty Page” memory region pending a write to the disk, this content would be prone to interception and modification - then the committed data to the disk would be the intercepted content.

Q: Is it mitigated by SELinux?
A: No, SELinux does not mitigate this vulnerability.

Q: Are Openstack, Ceph, Satellite, etc. vulnerable?
A: The product is not directly affected - the kernel is the affected component, and the affectedness of the system follows the RHEL version that the product is installed on.

Q: Will Red Hat release a kpatch?
A: The kpatch technology is unable to mitigate this vulnerability, thus there will be no kpatch released.

Q: Why is RHEL 8 affected, but is not vulnerable?
A: The currently know exploits depends on the functionality inserted by the upstream kernel commit f6dd97558 - which is not present in the RHEL8 kernel, hindering the exploitation.

Q: Is there any configuration / user configurable clause that can be modified and change the system affectedness/vulnerability?
A: No, there are no configuration clauses that can impact the system’s affectedness/vulnerability.

Q: Is there any special requirement to carry out the exploit?
A: The attacker must be a local user with execution privileges in the system.

Red Hat thanks Max Kellermann (CM4all) for reporting this vulnerability




How to use GPG to verify signed content from Product Security


Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.

Current Customers and Partners

Log in for full access

Log In

Hi Team,

Do you have rough ETA for this mitigation ?

As mentioned above - there is no mitigation available for this flaw. Customers should update to fixed packages "once they are available".

Hi, we will be releasing security errata with updated Kernel packages when ready. We will update this article with links to them as soon as we can. Providing an expected release date doesn't work because of potential for unknown problems to occur during testing.

Thank you for the detail.

Hi, I'm happy to note that yesterday the mitigation/fixes were released and available for download. Please see the links within the table - https://access.redhat.com/security/vulnerabilities/RHSB-2022-002#updates-for-affected-products


Can you please explain this statement from the FAQ?

Q: Why is RHEL 8 affected, but is not vulnerable? A: The current exploit depends on the functionality inserted by the upstream kernel commit f6dd97558 - which is not present in the RHEL8 kernel.

I take this to mean that exploit does not function or am I mistaken. Does this mean that Red Hat is determining whether there are further exploits related to pipe_buffer allocation affecting Red Hat's build of the kernel/linux?

Hi, The proof of concept and known exploits require specific code that is not within Red Hat's kernels. Due to the nature of our back porting and patches previously applied we were partially affected, and known attack paths do not work. We could not be 100% certain that there wasn't any others, even though we are not aware of any. We have released updated kernels - listed within https://access.redhat.com/security/vulnerabilities/RHSB-2022-002#updates-for-affected-products - which address the specific bad code.

Why was Red Hat Satellite not detected in this vulnerability? Red Hat Insight shows a list of affected systems, but The Red Hat Satellite doesn't.

Hello to all, @Kriangsak Red Hat Insight is pro active (cloud intelligence expertise), it can see beyond the packages in the configuration and the satellite for me can see only what it is (locally inside db local) in term of patching.

Red Hat Insight is amazing but your security company team seems to accept the idea of cloud (external data even if it can be protected), if you could, don't hesitate, take/activate Red Hat Insight on your server with a configuration accepted by the security /cybercurity of your company in complement of Red Hat Satellite.


Thank you for you detail , After that I found the Red Hat satellite was notified the list of affected system in this vulnerability on March 10th. Notify 2 days later than Red Hat Insight.

Any reason why previous RHEL8 kernels like RHEL 7 and earlier did not get affected by this Dirty pipe vulnerablity.

Hi, RHEL 7 is not affected as the kernel code does not contain the bad code. The bad code was introduced in the upstream kernel in newer code that is not part of RHEL 7.

Any idea when Red Hat OpenShift Container Platform 4 impact get clear?

If I'm not mistaken they are releasing it as 4.9.25, however it's currently only in the candidate channel. Not sure about 4.10!?

This week's release did not contain the fix - this is scoped for inclusion in a further version.

The OpenShift impact is the same as the RHEL 8 impact: Affected (flawed code present) but not vulnerable (not exploitable).


RHEL 8.1 (0otpa), kernel version: 4.18.0-147.el8.x86_64, affected this vulnerability right?

Thank you,

Yes, RHEL 8.1 is vulnerable. It requires Update Services for SAP Solutions in order to obtain the RHEL 8.1 fix.

Thank you bro, If i do not use software SAP Solutions, should be update the system? To update, should be update from RHEL 8.1 to RHEL 8.4 (latest of RHEL 8) to advanced secure?

If you have Extended Update support which is included in Premium subscription, then you should update from RHEL 8.1 to RHEL 8.4 for security updates. Otherwise, you should update to RHEL 8.5 which is the latest RHEL release.

Thanks you :)