Merge branch 'main' into staging

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

Author: garloff

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

@@ -81,6 +81,27 @@ _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.
+
+>>>>>>> main
 ## Impact
 
 Any system where normal (non-root) users can log in to execute code under their
@@ -124,18 +145,20 @@ 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.
+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
+# 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
@@ -144,6 +167,16 @@ 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.
@@ -211,7 +244,7 @@ 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;
+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
@@ -235,10 +268,40 @@ in the meantime, as advised above.
 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.
@@ -254,3 +317,6 @@ SCS security contact is [security@scs.community](mailto:security@scs.community),
 - 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.

community/tools/zuul.md

@@ -2,7 +2,7 @@
 
 ## Zuul CI/CD pipelines and project gating
 
-Since we are expecting a lot of pipelines beeing created and used GitHub actions won't keep up
+Since we are expecting a lot of pipelines being created and used GitHub actions won't keep up
 well. We also expect cross-repository and even cross-project dependencies. Therefore we decided to
 use Zuul as our main pipeline solution.
 
@@ -19,9 +19,9 @@ Note: This needs to be updated!
     - the merge-mode which should be used to auto-merge
     - the jobs to run in each pipeline (gh_check, gh_gate, gh_post, gh_tag)
     - these [pipelines](https://github.com/SovereignCloudStack/zuul-config/blob/main/zuul.d/) are triggered by events
-    - ihere are [some default jobs](https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks)
+    - here are [some default jobs](https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks)
 - If you have _self-defined_ jobs, you need to create a folder _.playbooks_
-  - this folder containers ansible playbooks which will be triggered
+  - this folder contains ansible playbooks which will be triggered
 
 ### General information about Zuul