Erkennungsskript für CVE-2026-31431 (Copy Fail), das Kernel-Version, Patch-Vorhandensein, Kernel-Konfigurationen, AF_ALG-Socket-Verfügbarkeit, setuid-Binaries und Gegenmaßnahmen prüft, um den Verwundbarkeitsstatus auf Linux-Systemen zu bestimmen.
Nur Erkennung. Ein funktionierender PoC existiert bereits unter copy.fail/#exploit. Dieses Skript richtet sich an Systemadministratoren und Sicherheitsteams, die feststellen möchten, wo sie verwundbar sind – oder nach dem Patchen immer noch verwundbar sind.
Am 29. April 2026 wurde eine Schwachstelle namens Copy Fail (CVE-2026-31431) vom Xint Code Research Team öffentlich bekannt gegeben. Es handelt sich um einen Logikfehler, der seit etwa 2017 – fast ein Jahrzehnt – still im Linux-Kernel vorhanden ist und es jedem unprivilegierten lokalen Benutzer ermöglicht, Root-Rechte zu erlangen.
Nicht „Root unter bestimmten Bedingungen mit etwas Glück und günstigem Wind.“ Sondern einfach... Root. Zuverlässig. Auf praktisch jeder großen Linux-Distribution.
Es betrifft Ubuntu, Amazon Linux, RHEL, SUSE und alles andere, das in den letzten ~8 Jahren einen Mainstream-Kernel ausführt. Gleiches Skript, keine Neukompilierung, keine distributionsspezifischen Anpassungen erforderlich.
Ja, es ist so schlimm, wie es klingt.
Der Linux-Kernel verfügt über ein Krypto-Subsystem, auf das unprivilegierte Benutzer über AF_ALG-Sockets zugreifen können. Es gibt einen Mechanismus namens splice(), der Dateidaten direkt in dieses Subsystem einspeisen kann, ohne sie zu kopieren – was bedeutet, dass die im Speicher zwischengespeicherte Kopie einer Datei (der „Page Cache“) in einer kryptografischen Operation landet.
Ein bestimmter Algorithmus – authencesn, der für IPsec Extended Sequence Numbers verwendet wird – hat eine Besonderheit: Er verwendet den Ausgabepuffer als Scratch-Space und schreibt 4 Bytes geringfügig über die vorgesehene Stelle hinaus. Normalerweise harmlos. Aber wenn Page-Cache-Seiten einer setuid-Binärdatei wie /usr/bin/su in diesen Ausgabepuffer verkettet werden (dank einer „Optimierung“ von 2017 in algif_aead.c), landen diese 4 Bytes direkt in der zwischengespeicherten Kopie der Binärdatei im Kernel.
Die Operation schlägt mit einem Fehler fehl. Der Kernel markiert diese Seite nie als „dirty“. Die Datei auf der Festplatte bleibt unberührt. Dateiintegritätstools, die Prüfsummen auf der Festplatte prüfen, sehen nichts Falsches.
Aber der Page Cache ist das, was ausgeführt wird. Und su ist setuid root.
Der vollständige technische Bericht ist unter xint.io verfügbar und wirklich lesenswert.
Sieben aus der ursprünglichen Veröffentlichung plus sechs neue Prüfungen zur Schließung von Erkennungslücken:
| # | Prüfung | Worauf sie prüft |
|---|---|---|
| 1 | Kernel-Version | Liegt dieser Kernel im betroffenen Bereich (4.10–6.14)? |
| 2 | Patch-Vorhandensein | Ist der Fix-Commit tatsächlich in Ihrem laufenden Kernel? |
| 3 | algif_aead-Modul | Ist das verwundbare Modul geladen oder ladbar? |
| 4 | CONFIG_CRYPTO_AUTHENC (neu) | Ist CONFIG_CRYPTO_AUTHENC fest eingebaut (=y) oder als Modul (=m)? Diese einzelne Option baut sowohl authenc als auch authencesn. Fest eingebaut bedeutet, dass die Modprobe-Blacklist-Mitigation wirkungslos ist. |
| 5 | CONFIG_CRYPTO_USER_API_AEAD (neu) | Ist die AF_ALG-AEAD-Benutzerschnittstelle überhaupt einkompiliert? Wenn nicht, ist der gesamte Exploit-Pfad zur Kompilierzeit geschlossen. |
| 6 | AF_ALG-Socket | Kann ein unprivilegierter Benutzer gerade jetzt einen öffnen? |
| 7 | Python os.splice | Ist der reine Python-Exploit-Pfad verfügbar? |
| 8 | Setuid-Binärdateien | Erweiterte Liste lesbarer setuid-root-Ziele auf dem System. |
| 9 | Mitigationen | AppArmor, SELinux, seccomp — was ist vorhanden? |
| 10 | Benutzer-Namespaces (neu) | Sind unprivilegierte Benutzer-Namespaces aktiviert? (Blockiert Copy Fail nicht direkt, beeinflusst aber die breitere lokale Privesc-Oberfläche.) |
| 11 | Transparente Hugepages (neu) | THP-Status — kann die Page-Cache-Ausrichtung und die Exploit-Zuverlässigkeit beeinflussen. |
| 12 | Umgebungserkennung (neu) | Docker/Container/VM-Kontext — Container teilen den Host-Kernel; der Host ist das, was gepatcht werden muss. |
| 13 | Root-Benutzer-Warnung (neu) | Warnt, wenn als Root ausgeführt, da mehrere Prüfungen für Root unabhängig von unprivilegierten Einschränkungen falsch positive Ergebnisse liefern. |
Das Bash-Skript deckt dieselbe Kernerkennungslogik ab, lässt jedoch drei Python-spezifische Punkte aus:
| # | Prüfung | Hinweise |
|---|---|---|
| 1 | Kernel-Version | |
| 2 | Patch-Vorhandensein | |
| 3 | algif_aead-Modul | |
| 4 | AF_ALG-Socket | Verwendet Python als Helfer, falls verfügbar; fällt auf Kernel-Konfigurationsinferenz zurück |
| 5 | Setuid-Binärdateien | Erweiterte Liste, wie in der Python-Version |
| 6 | Mitigationen | AppArmor, SELinux, seccomp |
| 7 | CONFIG_CRYPTO_AUTHENC | |
| 8 | Benutzer-Namespaces | |
| 9 | Transparente Hugepages | |
| 10 | Umgebungserkennung |
Nicht im Shell-Skript enthalten (im Vergleich zu Python):
| Fehlende Prüfung | Grund |
|---|---|
| CONFIG_CRYPTO_USER_API_AEAD | Noch nicht implementiert — geplant |
| Python os.splice-Verfügbarkeit | Für ein Shell-Skript nicht anwendbar |
| Root-Benutzer-Warnung | Noch nicht implementiert — geplant |
Keines der Skripte repariert oder exploitet etwas. Sie sagen Ihnen die Wahrheit über Ihr System, damit Sie entsprechend handeln können.
# Skript klonen oder herunterladen, dann:
python3 cve-2026-31431-detect.py
Das war's. Farbcodierter Bericht mit einer Zusammenfassung am Ende.
Das Skript beendet sich mit einem Nicht-Null-Code bei verwundbaren Befunden, was es für den Einsatz in Pipelines geeignet macht:
| Code | Bedeutung |
|---|---|
0 | Keine verwundbaren Bedingungen gefunden |
1 | Eine oder mehrere verwundbare Bedingungen gefunden |
# Beispiel: CI-Schritt fehlschlagen lassen, wenn der Host verwundbar ist
python3 cve-2026-31431-detect.py
rc=$?
if [ $rc -eq 1 ]; then
echo "VERWUNDBAR — Deployment blockieren"
elif [ $rc -ne 0 ]; then
echo "FEHLER — Skript konnte nicht abgeschlossen werden (Exit $rc)"
fi
CVE-2026-31431 'Copy Fail' — Schwachstellenerkennung
authencesn Page-Cache-Korruption / lokale Privilegieneskalation
Ausgeführt als uid=1001, euid=1001
=== Kernel-Version ===
[VERWUNDBAR] Kernel-Version
Grund : Kernel liegt im verwundbaren Bereich (4.10 – 6.14)
Detail : Release: 6.12.0-124.45.1.el10_1 — Patch-Status muss bestätigt werden
=== CONFIG_CRYPTO_AUTHENC (Kernel-Konfiguration) ===
[VERWUNDBAR] CONFIG_CRYPTO_AUTHENC
Grund : Als Modul gebaut (=m): lädt automatisch bei AF_ALG bind(); Modprobe-Blacklist ist die korrekte Mitigation
=== CONFIG_CRYPTO_USER_API_AEAD (Kernel-Konfiguration) ===
[VERWUNDBAR] CONFIG_CRYPTO_USER_API_AEAD
Grund : AF_ALG-AEAD-Schnittstelle ist ein ladbares Modul — unprivilegierte Benutzer können über AF_ALG-Sockets auf das Krypto-Subsystem zugreifen
...
SYSTEM IST WAHRSCHEINLICH VERWUNDBAR GEGENÜBER CVE-2026-31431
Empfohlene Maßnahmen:
1. Wenden Sie das Kernel-Update Ihrer Distribution für CVE-2026-31431 an
2. Bis zum Patch das Modul auf die Blacklist setzen:
echo 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
HINWEIS: Dies ist NUR wirksam, wenn CONFIG_CRYPTO_AUTHENC=m (Modul).
Wenn CONFIG_CRYPTO_AUTHENC=y (fest eingebaut), ist Patchen die einzige Lösung.
Ein begleitendes Bash-Skript (cve-2026-31431-detect.sh) ist für Umgebungen verfügbar, in denen Python nicht vorhanden ist oder shell-native Werkzeuge bevorzugt werden. Es führt 10 der 13 Prüfungen durch — siehe die Prüfungsvergleichstabelle oben für Details zu den Unterschieden.
# Grundlegende Ausführung
bash cve-2026-31431-detect.sh
# JSON-Ausgabe — geeignet für SIEM-Erfassung, Ansible-Fakten, Log-Aggregation
bash cve-2026-31431-detect.sh --json > scan-results.json
# Quiet-Modus — nur die Zusammenfassung ausgeben (nützlich in CI-Logs)
bash cve-2026-31431-detect.sh --quiet
# ANSI-Farben deaktivieren (für Logdateien)
bash cve-2026-31431-detect.sh --no-colour
Das Shell-Skript verwendet dieselben Exit-Codes (0 = OK, 1 = verwundbar) und erzeugt eine äquivalente JSON-Ausgabe für den Pipeline-Einsatz. Wenn Python 3 auf dem System verfügbar ist, verwendet das Shell-Skript es für den Live-AF_ALG-Socket-Test; andernfalls fällt es auf Kernel-Konfigurationsinferenz zurück.
Die eigentliche Lösung ist das Patchen Ihres Kernels. Prüfen Sie die Sicherheitshinweise Ihrer Distribution.
| Distribution | Wo nachsehen |
|---|---|
| Ubuntu | ubuntu.com/security/CVE-2026-31431 |
| RHEL / Amazon Linux | dnf update kernel |
| SUSE | zypper update kernel-default |
| Debian | apt update && apt upgrade |
Wenn die CONFIG_CRYPTO_AUTHENC-Prüfung =m meldet (als Modul gebaut, nicht fest eingebaut), können Sie es auf die Blacklist setzen:
echo 'install algif_aead /bin/false' > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
Wichtig: Diese Mitigation hat keine Wirkung, wenn
CONFIG_CRYPTO_AUTHENC=y(fest eingebaut). In diesem Fall ist das Patchen des Kernels die einzige Lösung. Die CONFIG_CRYPTO_AUTHENC-Prüfung im Skript sagt Ihnen, in welcher Situation Sie sich befinden. Beachten Sie, dassCONFIG_CRYPTO_AUTHENCder korrekte Kernel-Konfigurationsschlüssel ist — er baut sowohl dieauthenc- als auch dieauthencesn-Module aus einer einzigen Option.
Dies kann IPsec beeinträchtigen, wenn Sie es verwenden — verifizieren Sie vor einem flottenweiten Einsatz.
Der Upstream-Fix ist dieser Commit — er macht die In-Place-AEAD-Optimierung von 2017 in algif_aead.c rückgängig, indem er die Quell- und Ziel-Scatterlists trennt, sodass Page-Cache-Seiten nicht mehr im beschreibbaren Ziel landen können.
Wenn Sie dies in einem Docker-Container, Kubernetes-Pod oder einer anderen Container-Umgebung ausführen, wird das Skript Sie warnen: Container teilen den Host-Kernel. Die Schwachstelle liegt im Kernel, nicht im Container-Image. Sie müssen den Host bewerten und patchen.
# GitHub Actions
# Der Schritt schlägt natürlich fehl und blockiert die Pipeline, wenn das Skript mit 1 endet.
# Keine zusätzliche Konfiguration erforderlich — Nicht-Null-Exit-Codes lassen Schritte standardmäßig fehlschlagen.
- name: CVE-2026-31431 prüfen
run: |
python3 cve-2026-31431-detect.py
rc=$?
if [ $rc -eq 1 ]; then
echo "VERWUNDBAR — Pipeline blockiert"
exit 1
elif [ $rc -ne 0 ]; then
echo "FEHLER — Erkennungsskript konnte nicht abgeschlossen werden (Exit $rc)"
exit $rc
fi
# Ansible
# Verwendet playbook_dir, um sicherzustellen, dass der Skriptpfad korrekt aufgelöst wird.
# failed_when prüft auf jeden Nicht-Null-Exit (Schwachstelle ODER Skriptfehler).
- name: Auf CVE-2026-31431 prüfen
script: "{{ playbook_dir }}/cve-2026-31431-detect.py"
register: cve_check
failed_when: cve_check.rc != 0
# Nagios / Monitoring-Check (Shell-Skript — unterstützt Exit-Codes nativ)
bash cve-2026-31431-detect.sh --quiet
# Exit 0 = OK, Exit 1 = KRITISCH (verwundbar)
# JSON-Ausgabe für SIEM / Log-Aggregation (Shell-Skript)
bash cve-2026-31431-detect.sh --json --quiet > /var/log/cve-2026-31431-$(hostname)-$(date +%Y%m%d).json
| Datum | Ereignis |
|---|---|
| 2026-03-23 | An das Linux-Kernel-Sicherheitsteam gemeldet |
| 2026-03-24 | Bestätigt |
| 2026-03-25 | Patches vorgeschlagen und überprüft |
| 2026-04-01 | Fix in den Mainline-Kernel übernommen |
| 2026-04-22 | CVE-2026-31431 zugewiesen |
| 2026-04-29 | Öffentliche Offenlegung |
Dank an Taeyang Lee bei Theori für die ursprüngliche Forschungserkenntnis und das Xint Code Research Team für den vollständigen Offenlegungsbericht.
Einen falsch positiven Befund gefunden? Eine Distribution, die übersehen wird? Eine Kernel-Konfiguration, die geprüft werden sollte? Pull Requests sind willkommen. Das Ziel ist ein genaues Signal, nicht nur beängstigender roter Text.
Dieses Tool wird wie besehen für defensive Sicherheitszwecke bereitgestellt. Richten Sie es nur an Systemen aus, deren Bewertung Sie autorisiert sind. Seien Sie nicht seltsam damit.