Merge branch 'feat/kernel-lpe-202605' into staging

Author: garloff

blog/2026-05-10-kernel-root-exploits.md

@@ -5,7 +5,7 @@ authors: [garloff]
 tags: [security, linux, cve, copy.fail, dirtyfrag]
 ---
 
-## Linux root exploits (Local Privilege Escalation) copy.fail and Dirty Frag
+## Linux root exploits (Local Privilege Escalation)
 
 Unix is designed as a multi-user system. Different users have their own
 files and processes and can work without interference from others.
@@ -32,6 +32,8 @@ We don't normally report about these LPEs. They get fixed by the upstream Linux
 developers, shipped as stable updates by the maintainers and shipped to the end
 users via kernel updates from the Linux distributors.
 
+## copy.fail and Dirty Frag
+
 The currently highly visible Linux kernel issues [copy.fail](https://copy.fail/)
 and [Dirty Frag](https://github.com/V4bel/dirtyfrag) are both LPEs (local root
 vulnerabilities). The reason we report about them is that they both affect
@@ -85,12 +87,12 @@ Any system where normal (non-root) users can log in to execute code under their
 own control is no longer secure: The users can use the publicly available
 exploits to gain root privileges and get access to whatever the (virtual)
 machine has access to. This means accessing other user's data as well as secrets
-that are stored by the system administrator.
+that may be stored by the system administrator.
 
 Such systems are less common these days than they were 20 years ago. The reason
-is that virtualization has become a commodity, so individual users may use their
-own virtual machine rather than having access to a shared (virtual) machine
-in many scenarios.
+is that virtualization has become a commodity, so in many scenarios, individual
+users may use their own virtual machine rather than having access to a shared
+(virtual) machine.
 
 Note that this vulnerability does NOT break the isolation of virtual machines.
 VMs remain as securely isolated as they would be without this vulnerability.
@@ -122,7 +124,8 @@ The fixes for Dirty Frag are still in development as of May 8. The first fixes
 have been merged upstream and released in 7.0.5, 6.18.28, 6.12.87, 6.6.138,
 6.1.172, 5.15.206 and 5.10.255 but there is
 [more to come for rxrpc](https://lwn.net/ml/all/2026050859-ahead-anchovy-05e2@gregkh/).
-The responsible disclosure process for Dirty Frag was unfortunately broken,
+The responsible disclosure process for Dirty Frag unfortunately failed due to the
+[patches being spotted](https://www.openwall.com/lists/oss-security/2026/05/07/12),
 so the upstream maintainers and the distributors this time did not have time
 to carefully prepare and test fixes ahead of the publication of the issue.
 So we have to expect that it will take a few days until all Linux distributor
@@ -176,12 +179,14 @@ and provide them short-term via their image service (glance).
 The default implementation with SCS Cluster Stacks is vulnerable; the current
 node images have a kernel that is affected by this weakness. This allows a user
 to break out of the containers running in the cluster to take over the node
-VM and other containers. With Cluster-API and the SCS Cluster Stacks building
+VM and other containers.
+
+With Cluster-API and the SCS Cluster Stacks building
 on them, creating, updating and removing Kubernetes clusters has become
 a commodity; it is thus normal to create clusters per development team and
 not share them. In this scenario, the break out may allow a developer to
-take over containers from his team mates which is not a real danger in many
-setups. For cluster setups across teams or worse for setups where several
+take over containers from his team mates which may not constitute a real danger
+in many setups. For cluster setups across teams or worse for setups where several
 clusters that belong to different entities share a control plane, this becomes
 more serious.
 
@@ -225,6 +230,11 @@ images and then perform the rolling upgrade. If their use scenario puts
 them at increased risk, they are advised to prevent the module loading
 in the meantime, as advised above.
 
+## SCS community infrastructure
+
+The SCS community infrastructure was secured on May 8 by disabling the
+relevant modules.
+
 ## Thanks
 
 The authors would like to thank Taeyang Lee at Xint (who initiated the
@@ -236,9 +246,11 @@ getting fixes out.
 ## Sovereign Cloud Stack Security Contact
 
 SCS security contact is [security@scs.community](mailto:security@scs.community), as published on
-[https://scs.community/.well-known/security.txt](https://scs.community/.well-known/security.txt).
+[https://sovereigncloudstack.org/.well-known/security.txt](https://scs.community/.well-known/security.txt).
 
 ## Version history
 
 - Initial Draft, v0.1, 2026-05-08, 17:15 CEST.
 - kubectl node-shell instructions, v0.2, 2026-05-09, 12:45 CEST.
+- Mention succssful patching of community infra, v0.3, 2026-05-09, 13:30 CEST.
+- Correct facts on the failure of the responsible disclosure. Release as v1.0, 2026-05-09, 20:00 CEST.