Mention that we patched community infra.

Signed-off-by: Kurt Garloff <kurt@garloff.de>

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.
@@ -176,12 +178,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 +229,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
@@ -242,3 +251,4 @@ SCS security contact is [security@scs.community](mailto:security@scs.community),
 
 - 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.