Sovereign Cloud Stack

One platform — standardized, built and operated by many.

Sovereign Cloud Stack Security Advisory dirty pipe

Christian Berendt, Kurt Garloff, Felix Kronlage-Dammers March 07, 2022

The vulnerability

On Fri, 2022-03-07, a failure in the Linux kernel code to properly initialize the flags field of pipe buffers became widely known as “dirty pipe” (CVE-2022-0847). The issue had been discovered and responsibly disclosed by Max Kellermann from IONOS SE. The bug allows any local user on a system to overwrite data in any file regardless of permissions and thus creates a trivial local root exploit. Even the page cache of read-only mappings can be overwritten (not leaving any traces on persistent storage).

The issue was exposed (not introduced) by kernel commit f6dd975583bd and affects Linux kernels 5.8 and newer. It was fixed with commit 9d2231c5d74e and is also addressed in the stable kernels 5.16.11, 5.15.25 and 5.10.102.

More details can be found on

SCS reference implementation

The host images in the SCS reference implementation come from the OSISM project and are all built on top of Ubuntu 20.04 LTS. To the best of our knowledge, the kernels used there are NOT affected by the issue. The exploit code fails to alter the page cache there. We are waiting to get an official announcement from Canonical for a final confirmation.

The management host deployed by the automation for our cluster management is using an Ubuntu 20.04 LTS image by default – it is thus not affected. We use cluster-api images for the kubernetes clusters provided by OSISM. These are built on top of Ubuntu 20.04 LTS and thus not affected either.

Cloud operators often provide popular Linux images as a convenience for their customers. These are not provided by SCS. Some of these Linux images are affected, e.g. newer non-LTS versions of Ubuntu, Fedora or Arch Linux. These should be updated to support the customers in protecting their VMs.

Mitigation and fix

At this time, for cloud providers using the SCS reference implementation, we see no required actions to protect the infrastructure, as the SCS reference implementation does not use any images that use the affected kernels.

We recommend SCS operators to double check that no supporting system uses a vulnerable kernel. Furthermore, operators may have chosen newer kernels (e.g. the hardware enablement series from Ubuntu) due to specific hardware requirements. In both cases, we recommend a short-term risk assessment and the scheduling of the installation of fixed kernels.

Most cloud operators provide images for the most popular Linux operating systems. We strongly recommend to replace them with updated images as soon as the Linux distributors have provided updated base images (which is the case for many distributors at this point). Note that SCS has defined metadata for images that allow users to see the build date. Any image that’s older than 2022-02-21 and has a Linux kernel version >= 5.8 will very likely be vulnerable.


We are in fact lucky that the Sovereign Cloud Stack reference implementation is not affected by this high-risk vulnerability. Avoiding too many different Linux distributions and choosing a version with good long-term support were deliberate choices, but of course these are no guarantee to not be affected. They intended to ensure we can react quickly and effectively if affected.

Images are built and tested nightly in the OSISM infrastructure; we would have pushed out new images within a day if we had been affected, so we have prepared to react to issues like this. We will however use the opportunity to double-check that our reactions would have worked.

Sovereign Cloud Stack Security Contact

SCS security contact is, as published on

Version history

About the authors

Kurt Garloff
CTO Sovereign Cloud Stack @ Open Source Business Alliance
While working on Physics as student and researcher in Dortmund, Wuppertal and Eindhoven, Kurt started to work with and on Linux, with first patches to the SCSI layer in the mid 90s. He has spent his post-university life in Open Source, as kernel engineer, leader of SUSE Labs (kernel, compiler, X11, security), and engineering and business leadership at SUSE. Since 2011 he has been working on Open Source cloud software, at Deutsche Telekom, as Freelancer, at T-Systems (as chief architect for the OTC) and also has been serving on the Open Infra Foundation's board. Since 2019 he has been pushing the Sovereign Cloud Stack idea which resulted in a publically funded project that he now technically leads. He still loves to occasionally write code (mostly python these days) or at least test out code from the colleagues and project. He spends his free time with his family or with running and playing table tennis.
Felix Kronlage-Dammers
Felix has been building (open source) IT Infrastructure since the late 90s - during high school he helped build and run an ISP specialized in providing UUCP over ssh. Between then and now felix has always been active in various open source development communities (from DarwinPorts, OpenDarwin to OpenBSD and nowadays the Sovereign Cloud Stack). His interests range from monitoring and observability over infrastructure-as-code to building and scaling communities and companies. A technician at heart he enjoys enabling others to do awesome stuff. He is part of the extended board of the OSBA and describes himself as an unix/open source nerd. If not working, doing OSS for fun and (non-)profit or spending time with his family, he is usually found on a road bike.