Overview of the Vulnerability
A vulnerability in the Linux kernel pipe implementation, known as CVE-2022-0847, allowed any process to overwrite data in arbitrary read-only files. Dubbed "Dirty Pipe," this flaw enabled attackers to modify files they had no permission to access, including files inside containers, regardless of your container security configurations.
The vulnerability affected Linux kernel versions from 5.8 onward. An attacker with local access could exploit this to modify any file on the system, including read-only files, setuid binaries, and files inside supposedly isolated containers.
Timeline of Events
February 2022: Researcher Max Kellermann discovers the vulnerability while investigating corrupted log files.
March 7, 2022: CVE-2022-0847 publicly disclosed after coordinated notification to Linux kernel maintainers.
March 2022: Kernel patches released across three stable branches: 5.16.11, 5.15.25, and 5.10.102.
Post-disclosure: Organizations running containerized workloads on unpatched kernels remained vulnerable, regardless of container runtime security configurations.
Failed Controls and Missing Measures
Container isolation failed at the kernel level. Namespace isolation, seccomp profiles, and AppArmor policies couldn't prevent this attack because the vulnerability existed below the container abstraction layer.
Missing Control: Host Kernel Patching Cadence
Many organizations treat container security as a container-level issue. You configure read-only root filesystems, drop capabilities, and run as non-root users. However, if your host kernel has a privilege escalation vulnerability, those container controls become ineffective.
The specific failure: teams lacked processes to track kernel CVEs separately from application CVEs. Your container image scanning catches vulnerable libraries in your application layer but doesn't alert you when the host kernel has a critical vulnerability.
Missing Control: Kernel Version Inventory
You can't patch what you don't track. Many teams couldn't quickly answer, "which of our hosts run kernel 5.8 or later?" The vulnerability required local access, but in a container environment, that means any compromised container could pivot to modifying files in other containers or on the host.
Relevant Standards and Requirements
ISO/IEC 27001:2022 Control 8.8 requires you to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures, including infrastructure vulnerabilities.
NIST 800-53 Rev 5 SI-2 requires organizations to identify, report, and correct system flaws, including operating system kernels. The control specifically calls for installing security-relevant software updates within organization-defined time periods.
PCI DSS v4.0.1 Requirement 6.3.3 states that security vulnerabilities are identified using reputable sources and that risk rankings are assigned. While PCI focuses on systems in the cardholder data environment, the principle applies: you need a process to identify kernel vulnerabilities affecting your infrastructure.
SOC 2 Type II CC7.1 requires detecting and addressing security incidents. A known kernel vulnerability with public exploit code qualifies as a detectable security risk requiring response.
The standards converge on a clear expectation: you must have a process to identify infrastructure vulnerabilities and remediate them within a defined timeframe.
Lessons and Action Items for Your Team
Action 1: Separate Kernel CVE Monitoring from Container CVE Monitoring
Add Linux kernel CVE feeds to your vulnerability management process. The only known fix for Dirty Pipe was upgrading to kernel versions 5.16.11, 5.15.25, or 5.10.102. Your container scanning tools won't tell you this—you need host-level vulnerability tracking.
Set up alerts for kernel CVEs with CVSS scores above 7.0. Subscribe to the linux-kernel mailing list or use a service that aggregates kernel security announcements.
Action 2: Build a Kernel Version Inventory
Create an automated inventory of kernel versions across your container hosts. A simple script running uname -r across your fleet and aggregating results gives you the data you need to respond quickly when the next kernel vulnerability arises.
Store this in your CMDB or asset inventory system. Tag hosts by kernel version so you can quickly identify affected systems.
Action 3: Define Kernel Patching SLAs Matching Container Patching SLAs
If you patch critical container vulnerabilities within 48 hours, your kernel patching timeline should be similar. Dirty Pipe demonstrated that kernel vulnerabilities can bypass all your container security controls.
Document these SLAs in your vulnerability management policy. Make kernel patches a regular part of your maintenance windows, not an "eventually" task.
Action 4: Test Container Workload Resilience to Host Reboots
Kernel patching often requires reboots. If you can't gracefully restart your container hosts without service disruption, you'll delay critical kernel patches.
Implement rolling updates for your container orchestration clusters. Verify that your workloads can tolerate node restarts. This isn't just for kernel patches—it's fundamental operational resilience.
Action 5: Re-evaluate Container Security Assumptions
Dirty Pipe breaks a core assumption: that file permissions and container isolation protect you from unauthorized file modification. Review your security documentation and threat models. Where have you assumed container isolation is sufficient?
Consider: if an attacker compromises a container, what files on the host or in other containers could they modify with a kernel exploit? This threat modeling exercise reveals where you need additional detective controls.
Action 6: Implement Host-Level File Integrity Monitoring
Since kernel vulnerabilities can bypass container isolation, add file integrity monitoring at the host level. Tools that detect unexpected modifications to critical files provide a detective control when preventive controls fail.
Focus on monitoring files that would be high-value targets: SSH authorized_keys, sudoers files, container runtime configurations, and systemd unit files.
The broader lesson: container security isn't just about securing containers. The host kernel is part of your attack surface. When you rely on kernel-provided isolation mechanisms, kernel vulnerabilities become container vulnerabilities. Your vulnerability management process must account for every layer of the stack, from your application dependencies down to the kernel version running on bare metal or your cloud provider's hypervisor.
