Update mitigation guidance and tools for CVE-2026-31431

disable-algif-aead/README.md

@@ -0,0 +1,26 @@
+# DaemonSet Mitigation for CVE-2026-31431 (Copy Fail)
+
+This directory contains a privileged DaemonSet mitigation for CVE-2026-31431. It edits the node's `/etc/modprobe.d` configuration to blacklist the vulnerable `algif_aead` module and sets the `initcall_blacklist=algif_aead_init` kernel parameter.
+
+### ⚠️ Known Limitations & Caveats
+Please be aware of the following issues before deploying this DaemonSet:
+* **Secure Boot:** This mitigation does not work if Secure Boot is enabled. The DaemonSet will enter an `Init:CrashLoopBackOff` state because Secure Boot prevents changes to the kernel command line boot options.
+* **Spot Nodes:** This mitigation is currently failing on Spot (Preemptible VM) nodes due to cgroup configuration errors during container initialization.
+* **Node Reboots:** Applying this DaemonSet will immediately reboot the affected nodes. 
+
+## Deployment Instructions
+
+**1. Label your target nodes:**
+To control the rollout, label your target nodes first:
+```bash
+kubectl label nodes <node-name> cloud.google.com/gke-algif-aead-disabled=true
+```
+
+**2. Apply the DaemonSet:**
+```bash
+kubectl apply -f daemonset.yaml
+```
+
+---
+
+Note: We do not recommend relying on containers as a strict security boundary. For stronger isolation, consider using GKE Sandbox.

spo-seccomp-mitigation/README.md

@@ -2,6 +2,8 @@
 
 This directory provides a mitigation for CVE-2026-31431 using the Kubernetes Security Profiles Operator (SPO). It uses a custom `SeccompProfile` that copies containerd's default allowed syscalls but blocks both `AF_VSOCK` and `AF_ALG` (socket family 38).
 
+This is the recommended mitigation for GKE Autopilot clusters and environments where running privileged DaemonSets is not allowed.
+
 ## Instructions
 
 **1. Install the Security Profiles Operator (SPO)**
@@ -17,7 +19,7 @@ kubectl apply -f seccomp-profile.yaml
 **3. Enable Binding on the Namespace**
 For the binding to take effect, you must label the target namespace to permit the Security Profiles Operator to modify pods within it:
 ```bash
-kubectl label ns my-namespace spo.x-k8s.io/enable-binding=true
+kubectl label ns <your-namespace> spo.x-k8s.io/enable-binding=true
 ```
 
 **4. Bind the Profile to Containers**
@@ -28,3 +30,6 @@ kubectl apply -f profile-binding.yaml
 
 **5. Restart Existing Pods**
 The binding is applied via a mutating webhook during pod creation. Existing pods must be restarted or recreated to pick up the new profile and be protected.
+
+---
+*Note: We do not recommend relying on containers as a strict security boundary. For stronger isolation, consider using GKE Sandbox.*