Merge branch 'main' into feat/node-22

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

Author: garloff

.nvmrc

@@ -1 +1 @@
-v22
+v22

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

@@ -0,0 +1,321 @@
+---
+slug: kernel_local_root_exploits
+title: Linux Kernel local root exploits CVE-2026-31431, -43284, -43500
+authors: [garloff]
+tags: [security, linux, cve, copy.fail, dirtyfrag]
+---
+
+## 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.
+Linux lives in that tradition. It has advanced the concept with namespaces
+where users can also have a private view on networking, process list, filesystems
+and other pieces that are traditionally shared (read-only) on a Unix system,
+also including some resource management to enhance performance isolation.
+
+It is the operating system's kernel's job to keep the separation safe; in
+particular, normal users must not achieve the system administrator (root)
+privileges. Where the kernel fails to ensure this, we have a "local root"
+vulnerability, a Local Privilege Escalation (LPE).
+
+The Linux kernel is a large and a complex beast. On one hand it has sophisticated
+mechanisms to get really good performance out of increasingly complex hardware.
+On the other hand, it comes with a huge variety of device drivers. From time to
+time, vulnerabilities are found, reported and fixed. The Linux kernel has several
+LPEs per year. Most of the time, they affect only a small fraction of users
+(typically by being located in a device driver or somewhat exotic feature)
+and often they are hard to exploit, needing to win a race condition with
+many attempts and sometimes causing crashes in trying (which may not go unnoticed).
+
+We don't normally report about these LPEs. They get fixed by the upstream Linux kernel
+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
+most Linux users (with kernels from the last 9 years) and are easy to exploit.
+
+Like [Dirty Pipe](https://dirtypipe.cm4all.com/) and before
+[Dirty Cow](https://dirtycow.ninja/), both LPEs rely on improper protection
+of the page cache.
+The Linux kernel keeps contents from file systems in the page cache; when code
+gets executed, it is mapped into your virtual memory. When the memory page is
+accessed and not yet loaded into your physical memory, a page fault occurs and
+the relevant blocks are loaded from disk — or the access is denied and your
+program receives `SIGSEGV` and is terminated. Copying pages is costly and the
+kernel avoids it to achieve higher performance. If you write to a memory page,
+the kernel may receive a page fault on a read-only mapping (that it created to
+avoid copying) and only then do the copy to create a private writable copy.
+This approach is called copy-on-write (COW) and is common in modern operating
+systems. If a page from the page cache is changed in memory, it is also marked
+"dirty", so the kernel knows it needs to write the changes back to the file system.
+
+In copy.fail, the `aead` crypto module did some cryptography in place, avoiding
+the need to allocate an extra buffer. Unfortunately, it requires 4 extra bytes
+under some conditions; normally aead is used by IPsec and that location is a
+designate place in a network buffer. However, a local attacker can make this
+write happen to a page cache page by using `splice`. This way, the copy of the
+`sudo` binary in the page cache can be overwritten, allowing to circumvent the
+safeguards there. The attacker can trivially become root — as the page is not
+dirtied, no trace of the corruption will be visible on the disk.
+[copy.fail](https://copy.fail/) has been assigned CVE-2026-31431.
+
+In Dirty Frag, a network buffer that is split over several fragments is not
+properly handled and the fragmented buffer is not properly COW'ed. The AEAD
+crypto operation then again overwrites 4 bytes. A local attacker can trigger
+this again become root very quickly by overwriting the page cache's view of
+`sudo`. (Of course other sensitive binary code could be overwritten in memory.)
+This can be triggered via the IPsec `esp_input` (for both IPv4 and IPv6) as well
+as via the `rxrpc` code. The esp variant requires the privilege to create user
+namespaces and then allows for easy 4 byte writes at a time. It has been assigned
+CVE-2026-43284. The rxrpc variant overwrites 8 bytes and doe not require the
+namespace creation privileges, but as these bytes are crypted,
+the user needs to brute force them in order to achieve a controlled result. This
+variant was assigned CVE-2026-43500.
+
+_Exploiting these vulnerabilities requires access to the system and the ability
+to execute code there, thus the categorization as Local Privilege Escalation (LPE),
+not Remote Code Execution (RCE)._
+
+## Update 2026-05-13: Fragnesia
+
+Yet another network fragment handling issue which fails to properly prevent
+in-place en/decryption which can be made to hit sensitive page cache contents
+that was put there with splice has been discovered with
+[Fragnesia](https://www.openwall.com/lists/oss-security/2026/05/13/3).
+It's a simple logic error where the sharing property is forgotten in buffer
+coalescing. It has gotten CVE-2026-46300.
+
+## Update 2026-05-15: ssh-keysaign-pwn
+
+This LPE is unrelated to the others; under certain circumstances, the kernel
+fails to prevent the dumping of process memory under ptraces, which can be used
+to read out sensitive data. As it can be used to read e.g. ssh keys, it has been called
+[ssh-keysign-pwn](https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn). It has
+gotten CVE-2026-46333.
+
+This vulerability allows local attackers to read sensitive data (Information
+Disclosure - ID) which may be useful to escalate privileges.
+
+## Impact
+
+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 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 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.
+These LPEs do NOT establish a virtualization escape.
+
+There is however a common scenario where individual users and workloads
+are running inside a container. The LPE also allows for escaping containers.
+Running a shell inside a kubernetes pod allows you to get control of the
+kubernetes node and thus of everything that your kubernetes cluster has
+access to. Running untrusted code in a container is thus very risky — something
+that will affect e.g. CI setups.
+
+## Fixes
+
+A fix to the Linux kernel for Copy.fail was silently merged at the end of March
+2026 (for 7.0-rc7) and also been merged to the stable kernel series (6.18.22,
+6.12.85, 6.6.137).
+It just disables the in-place optimization for `algif_aed`. As of early May,
+Linux distributors are currently underway to ship fixed kernels.
+Without a fixed kernel, a workaround is to place a file `copyfail.conf` in
+`/etc/modprobe.d/` with the contents:
+
+```shell
+# Temporary workaround for copy.fail CVE-2026-31431
+install algif_aead /bin/false
+```
+
+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/).
+Update 2026-05-11: 7.0.6 and 6.18.29 contain this last patch, older kernels don't need it.
+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
+manage to ship tested fixed kernels. Alma Linux has done so already, others are
+expected to follow soon.
+
+A fully effective workaround is again to prevent loading the affected modules
+by placing another file `dirtyfrag.conf` in `/etc/modprobe.d/`:
+
+```shell
+# Temporary workaround for Dirty Frag CVE-2026-43284, CVE-2026-43500, CVE-2026-46300
+# This breaks IPsec
+install esp4 /bin/false
+install esp6 /bin/false
+install rxrpc /bin/false
+```
+
+Note that these workarounds prevent IPsec from working.
+
+Update 2026-05-15: This mitigation helps against Fragnesia as well; AppArmor preventing
+unprivileged user namespaces (ubuntu) also helps. While a patch
+for Fragnesia was proposed, a fix has not been merged into the upstream kernel yet.
+Alma Linux has gone ahead and published a fixed kernel anyhow (for testing).
+
+Update 2026-05-15: The stable kernels 7.0.8, 6.18.31, 6.12.89, 6.6.139, 5.15.207, and
+5.10.256 contain a fix for the ptrace vulnerability (CVE-2026-46333 aka ssh-keysign-pwn).
+The latter is hard to mitigate, as there's no Security Module hook. Setting up a seccomp
+that disallows ptrace would help.
+
+If a system is suspected to already have been exploited, the system owner can
+dispose of the page cache by doing `echo 3 > /proc/sys/vm/drop_caches` as root
+and unload the affected modules to prevent re-exploitation.
+This will discard the modified page cache pages — however an attacker could have
+used its gained privileges to install further backdoors etc. into the system, so
+it will need to be reinstalled or fully audited to be considered trustable again.
+
+## SCS IaaS Cloud Provider exposure
+
+None of the control-plane / management systems in a normal SCS cloud infrastructure
+can be logged in by normal users. The LPE thus can not be exploited. However,
+should another exploit be found and used successfully, the LPEs may be used
+to escalate privileges further, e.g. breaking out of the containers that run
+the OpenStack services or Ceph or some of the management tools and thus remove
+one layer of a defense-in-depth concept.
+
+Cloud Providers are advised to install updated kernels to reestablish the defense.
+They can apply the module loading prevention measures in the meantime. Providers
+are advised to use this with care on the network nodes — if these need to support
+IPsec (e.g. for OpenStack's VPNaaS which is part of neutron), the non-loadable
+modules may prevent correct operation. Please note that there is no known remote
+exploit via IPsec, so a temporary trade-off to live without the defense-in-depth
+and not break IPsec (and this way create security and functionality issues or for
+customers) may be justified.
+
+Cloud providers often provide VM images for their customers.
+To support the customers to keep the security separation in the customer's VMs,
+they are advised to watch out for the availability of new distribution images
+and provide them short-term via their image service (glance).
+
+## SCS Kubernetes Provider exposure
+
+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
+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 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.
+
+Note that the LPE also removes a defense-in-depth mechanism, where a user of
+a service running in a k8s cluster exploits a vulnerability to be able to
+execute code in the container — the LPEs can then be used to escalate the
+privileges further.
+
+As soon as new kernels become available, the node images will be rebuilt and
+shipped with the next cluster stack patch releases. For users, the normal
+rolling upgrade will then be all that's needed to be secure against this LPE
+again.
+
+We will update this advisory as soon as new node images are available.
+
+For highly critical workloads, cluster operators can log in to the nodes
+and deploy the mechanisms to prevent loading the above-mentioned modules.
+(Again, this will break IPsec.) Note that logging in to nodes in an SCS
+Cluster Stack cluster is not possible by default; it requires booting
+into a rescue image (if the cluster runs on OpenStack) to inject an ssh
+key or to use a tool like kubectl-node-shell with the appropriate
+privileges.
+
+```bash
+for node in $(kubectl get nodes | grep -v '^NAME' | awk '{print $1;}'); do
+  kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable algif_aead (copy.fail)\ninstall algif_aead /bin/false" > /etc/modprobe.d/disable-aead-copyfail.conf'
+  kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable esp4, esp6, rxrpc (Dirty Frag)\ninstall esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false" > /etc/modprobe.d/disable-esp46-rxrpc-dirtyfrag.conf'
+done
+```
+
+## SCS Cloud users
+
+Customers of SCS IaaS clouds are responsible for their own VMs. For VMs
+that are exposed, they should use the documented workaround inside their VMs,
+online-update and reboot into a fixed kernel or redeploy their VMs based
+on a fixed upstream image.
+
+Customers that do their own Kubernetes Container Cluster Management
+with e.g. SCS Cluster Stacks are advised to watch out for new node
+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.
+
+## Outlook
+
+The density with which severe issues are currently found is notable. While the
+research in the referenced issues originated from human beings being suspicious
+that certain things were not handled correctly everywhere, they were assisted
+by AI tools in the search. This pattern is likely to turn up a relevant number
+of such issues which are reachable now using such help until we may enjoy a
+more quiet time again. Until a new class of weaknesses comes into the reach of
+yet more powerful AI tools.
+
+The other notable thing is that the quiet closing of issues within the Linux
+Kernel no longer works which has broken the responsible disclosure process
+that gave defenders some headway against attackers. One reason is that
+once a pattern emerges, several teams compete for speed to find related issues
+and decide in favor of disclosing before someone else finds it also. Another
+reason is that there are people that now use AI tools to analyze merged bugfixes
+to the kernel using AI tools - the fact that they are not flagged as security
+issues no longer is a good cover. So software distributors need to expect more
+of these occurences where they are struggling to patch software, validate the
+fixes and ship to customers before large-scale attacks happen. Operators will
+need to be fast as well.
+
+So yes, the times are changing in software security and open source software is
+hit first being the most accessible to security researchers. On the proprietary
+side, we can suspect similar research is happening, but whether the research
+teams also go for fame and visibility or maybe have other prevalent incentives
+is an open question.
+
+## Thanks
+
+The authors would like to thank Taeyang Lee at Xint (who initiated the
+research on copy.fail) and Hyunwoo Kim (@v4bel, who discovered Dirty Frag).
+Update 2026-05-15: They would also like to acknowledge William Bowling (V12) for Fragnesia
+and Jann Horn and Qualys for ssh-keysign-pwn.
+They would also like to thank the upstream Linux kernel maintainers and
+Linux distributors for their reliable work no handling the issues and
+getting fixes out.
+
+## Sovereign Cloud Stack Security Contact
+
+SCS security contact is [security@scs.community](mailto:security@scs.community), as published on
+[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.
+- Update on final rxrpc fix in stable kernels. v1.1, 2026-05-12, 08:45 CEST.
+- Add Fragnesia and ssh-keysign-pwn LPEs. v1.2, 2026-05-15, 17:15 CEST.
+- Add note on AI changing the game (outlook). v1.3, 2026-05-15, 17:30 CEST.