CVE-2026-31431 — „Copy Fail“

Lokale Privilegieneskalation im Linux-Kernel-Krypto-algif_aead-Subsystem.

Überblick

CVE-2026-31431, genannt „Copy Fail“, ist ein Logikfehler in der kryptografischen Vorlage authencesn des Linux-Kernels (algif_aead). Er ermöglicht einem nicht privilegierten lokalen Benutzer, einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache einer beliebigen lesbaren Datei durchzuführen, was genutzt werden kann, um eine setuid-Binärdatei zu modifizieren und Root-Zugriff zu erlangen.

• CVSS: 7.8 (Hoch)
• Betroffen: Alle gängigen Linux-Kernel, die seit 2017 ausgeliefert wurden
• Exploit: Ein 732-Byte-Python-Skript — keine Race Conditions, keine kernel-spezifischen Offsets
• Fix: Mainline-Commit a664bf3d603d

Zeitplan

Auswirkungsmatrix

Der Exploit erfordert zwei Dinge: einen AF_ALG-Socket (standardmäßig in allen Seccomp-Profilen erlaubt) und eine setuid-Binärdatei (z. B. /usr/bin/su). Die wichtigste Gegenmaßnahme ist allowPrivilegeEscalation: false — dies setzt das no_new_privs-Flag des Linux-Kernels über prctl(PR_SET_NO_NEW_PRIVS, 1), wodurch der Kernel setuid/setgid-Bits bei execve() ignoriert. Da der Exploit auf der Ausführung einer modifizierten setuid-Binärdatei basiert, blockiert dies den letzten Eskalationsschritt.

Dies ist kein OpenShift-spezifisches Feature — es funktioniert auf die gleiche Weise mit Vanilla-Kubernetes (Pod Security Standards Restricted), Docker (--security-opt no-new-privileges) und Podman. OpenShift erzwingt es lediglich standardmäßig über die restricted-v2 SCC, während andere Plattformen eine explizite Konfiguration erfordern.

RHEL 8 / RHEL 9

RHEL 8 und RHEL 9 werden mit Kerneln ausgeliefert, die den verwundbaren Code enthalten. Ein nicht privilegierter lokaler Benutzer mit Shell-Zugriff kann dies ausnutzen, um Root-Zugriff zu erlangen. Sofort patchen.

yum updateinfo list cves CVE-2026-31431
yum update kernel

OpenShift (4.x)

OpenShift läuft auf RHCOS, das den verwundbaren Kernel enthält. Die praktische Auswirkung hängt von den Security Context Constraints (SCC) der Workload ab.

Standard-Workloads mit der standardmäßigen restricted-v2 SCC sind nicht ausnutzbar, da allowPrivilegeEscalation: false erzwungen wird.

Pods, die mit erhöhten SCCs laufen (anyuid, privileged oder benutzerdefinierte SCCs, die allowPrivilegeEscalation: true erlauben), sind verwundbar. Dazu gehören üblicherweise:

• CI/CD-Build-Pods (Jenkins-Agenten, Tekton mit benutzerdefinierten SCCs)
• Legacy-Anwendungen, die anyuid erfordern
• Infrastruktur-Pods (Monitoring, Logging, Storage)

Direkter Node-Zugriff (z. B. über oc debug node/) ist immer verwundbar — standardmäßige lokale Privilegieneskalation, ohne Container-Isolation.

Testen

Ein Test-Pod wird bereitgestellt, um zu prüfen, ob die Exploit-Voraussetzungen in Ihrem Cluster erfüllt sind. Er versucht nicht, die Schwachstelle auszunutzen — er prüft nur:

1. Kann ein AF_ALG-Socket erstellt werden? (Kernel-Angriffsfläche erreichbar)
2. Ist no_new_privs gesetzt? (blockiert setuid-Eskalation)
3. Sind setuid-Binärdateien im Container-Image vorhanden?
4. Kernel-Version des zugrunde liegenden Nodes

Verwendung (Pod)

oc apply -f test-pod.yaml
oc logs cve-2026-31431-check
oc delete -f test-pod.yaml

Verwendung (Deployment)

Verwenden Sie die Deployment-Variante, um über mehrere Nodes zu testen, indem Sie Replicas skalieren oder Pod-Anti-Affinity verwenden:

oc apply -f test-deployment.yaml
oc logs -l app=cve-2026-31431-check
oc delete -f test-deployment.yaml

Exit-Codes

Erwartetes Ergebnis auf Standard-OpenShift

Auf einem Standard-OpenShift-Cluster mit restricted-v2 SCC sollten Sie Exit-Code 1 (teilweise exponiert) sehen: Der AF_ALG-Socket kann erstellt werden (RuntimeDefault-Seccomp blockiert ihn nicht), aber no_new_privs verhindert den setuid-Eskalationsschritt. Der veröffentlichte PoC wird nicht funktionieren, aber die Schwachstelle auf Kernel-Ebene ist weiterhin erreichbar — Patchen wird empfohlen.

Gegenmaßnahmen

1. Kernel patchen (P0)

Dies ist der einzige vollständige Fix. Aktualisieren Sie den Kernel auf allen Nodes und starten Sie neu.

Für OpenShift aktualisieren Sie auf eine RHCOS-Version, die den Fix enthält, und führen Sie einen rollierenden Node-Neustart durch.

2. algif_aead-Modul deaktivieren (Übergangslösung)

Wenn algif_aead als ladbares Modul kompiliert ist (CONFIG_CRYPTO_USER_API_AEAD=m):

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Dies funktioniert NICHT, wenn algif_aead fest eingebaut ist (=y), was auf RHCOS der Fall ist. Prüfen Sie mit:

modinfo algif_aead 2>&1 | grep builtin
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

3. AF_ALG über Seccomp blockieren (OpenShift)

Wenn das Kernel-Modul fest eingebaut ist, ist die einzige Pre-Patch-Gegenmaßnahme für Container das Blockieren des socket(AF_ALG, ...)-Syscalls über ein benutzerdefiniertes Seccomp-Profil.

Das Seccomp-Profil über MachineConfig bereitstellen

Erstellen Sie die MachineConfig, um das Profil auf allen Nodes zu platzieren (für Control-Plane-Nodes mit role: master wiederholen):

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-seccomp-deny-af-alg
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /var/lib/kubelet/seccomp/deny-af-alg.json
          mode: 0644
          contents:
            source: data:application/json;charset=utf-8;base64,ewogICJkZWZhdWx0QWN0aW9uIjogIlNDTVBfQUNUX0FMTE9XIiwKICAic3lzY2FsbHMiOiBbCiAgICB7CiAgICAgICJuYW1lcyI6IFsic29ja2V0Il0sCiAgICAgICJhY3Rpb24iOiAiU0NNUF9BQ1RfRVJSTk8iLAogICAgICAiYXJncyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaW5kZXgiOiAwLAogICAgICAgICAgInZhbHVlIjogMzgsCiAgICAgICAgICAib3AiOiAiU0NNUF9DTVBfRVEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9

Der Base64-Inhalt dekodiert zu:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Hinweis: Das Anwenden einer MachineConfig löst einen rollierenden Node-Neustart aus.

Das Profil in Pod-Specs referenzieren

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: deny-af-alg.json

Clusterweite Alternative

Um alle Container ohne Änderung der Pod-Specs zu schützen, überschreiben Sie das CRI-O-Standard-Seccomp-Profil (/etc/crio/seccomp.json) über MachineConfig, indem Sie die AF_ALG-Filterregel zum vorhandenen Profil hinzufügen.

4. Ihre SCCs auditieren

Identifizieren Sie Pods, die mit erhöhten Privilegien laufen:

# Pods finden, die nicht restricted-v2 verwenden
oc get pods -A -o json | jq -r '
  .items[] |
  select(.metadata.annotations["openshift.io/scc"] != "restricted-v2") |
  "\(.metadata.namespace)/\(.metadata.name) → \(.metadata.annotations["openshift.io/scc"])"
'

Dies sind die Pods, bei denen die vollständige Exploit-Kette funktioniert. Priorisieren Sie Patchen oder Seccomp-Gegenmaßnahmen für Nodes, auf denen diese Workloads laufen.

Auswirkung der Deaktivierung von AF_ALG

Das Blockieren von AF_ALG-Sockets hat vernachlässigbare Auswirkungen auf die meisten Workloads. Die folgenden sind nicht betroffen:

• dm-crypt / LUKS
• kTLS
• IPsec
• OpenSSL / GnuTLS (Standard-Builds)

Nur Anwendungen, die explizit für die Verwendung der OpenSSL-afalg-Engine konfiguriert sind, sind betroffen.

Referenzen

• Copy Fail — Projektseite
• Red Hat CVE-2026-31431
• NVD — CVE-2026-31431
• RuntimeDefault blockiert AF_ALG nicht (juliet.sh)
• Xint — Copy Fail Write-Up
• The Register — Linux-Krypto-Code-Fehler