Über die Schwachstelle

CVE-2026-31431, öffentlich als Copy Fail bezeichnet, ist eine lokale Privilegieneskalations-Schwachstelle im Linux-Kernel, die mit dem Modul algif_aead verbunden ist, das die AEAD-Schnittstelle der Kernel-Userspace-Crypto-API über AF_ALG implementiert.

In der Praxis ermöglicht das Problem einem lokalen Benutzer mit niedrigen Privilegien, einen Logikfehler im Speicherverwaltungspfad dieses Subsystems auszunutzen und die Auswirkung auf eine vollständige Kompromittierung der Systemintegrität zu eskalieren. Der von kernel.org veröffentlichte und im NVD widergespiegelte Score ist CVSS 7.8 mit dem Vektor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, was bedeutet, dass der Angriff lokale Ausführung erfordert, aber hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit hat.

Wann es eingeführt und offengelegt wurde

• Die ausnutzbare Grundursache wurde im Jahr 2017 in den Kernel eingeführt, als eine In-Place-Optimierung zu algif_aead hinzugefügt wurde.
• Die CVE wurde am 22. April 2026 im NVD veröffentlicht.
• Eine breitere öffentliche Offenlegung des Problems unter dem Namen Copy Fail und mit einem öffentlichen Proof of Concept erfolgte am 29. April 2026.
• Der wichtigste Upstream-Fix wurde am 1. April 2026 committet, vor der breiten Offenlegung für Endbenutzer.

Was es ausnutzt

Laut den veröffentlichten technischen Advisories beruht der Fehler auf der Kombination von:

• der Kernel-AF_ALG-Schnittstelle
• dem Modul algif_aead
• einer 2017 eingeführten In-Place-Operationsoptimierung
• der Verkettung dieser Schnittstelle mit splice()

Das praktische Ergebnis ist die Fähigkeit eines lokalen Prozesses, einen kleinen kontrollierten Schreibvorgang in Seiten mit Page-Cache-Backing von lesbaren Dateien durchzuführen. Unter günstigen Bedingungen reicht das aus, um einen begrenzten lokalen Ausgangspunkt in eine root-Privilegieneskalation zu verwandeln.

Wie sich dies auf das Unternehmen auswirkt

Das eigentliche Risiko besteht nicht einfach darin, „einen anfälligen Linux-Kernel auszuführen“, sondern darin, lokalem Code mit geringem Vertrauen den Zugriff auf diesen Kernel-Pfad zu ermöglichen. In Unternehmensumgebungen bedeutet das in der Regel eine höhere Exposition auf:

• Multi-User-Servern
• Jump-Hosts und Bastionen
• CI/CD-Runnern
• containerisierten Workloads, die nicht vertrauenswürdigen Code ausführen
• Kubernetes-Clustern
• VMs, die Automatisierung, Agents, Plugins oder Drittanbieter-Jobs hosten

Wenn ein Angreifer bereits über eine Form der lokalen Ausführung verfügt, selbst ohne root, kann diese CVE der nächste Schritt zur Host-Kompromittierung werden. In der Praxis erweitert das das Risiko von:

• vollständiger Serverübernahme
• Modifikation lokaler Binärdateien oder Artefakte
• Diebstahl von Anmeldeinformationen, Tokens und residenten Geheimnissen
• lateraler Bewegung zu anderen Assets
• Sabotage von Pipelines und Build-Ketten

Wofür das Modul algif_aead verwendet wird

algif_aead ist Teil der Kernel-Userspace-Crypto-Schnittstelle (AF_ALG). Es ermöglicht Anwendungen, kryptografische Kernel-Primitive über Sockets zu verwenden, insbesondere AEAD-Operationen (Authenticated Encryption with Associated Data).

Dieses Modul ist für die meisten Standard-Server-Workloads in der Regel nicht essenziell. Gemäß den von CERT-EU veröffentlichten Minderungsrichtlinien sollte die Deaktivierung von algif_aead als temporäre Minderung:

• dm-crypt oder LUKS nicht beeinträchtigen
• kTLS nicht beeinträchtigen
• IPsec/XFRM nicht beeinträchtigen
• OpenSSL, GnuTLS, NSS oder SSH im Standardgebrauch nicht beeinträchtigen

Andererseits kann die Deaktivierung Folgendes beeinträchtigen:

• Anwendungen, die explizit für die Verwendung der afalg-Engine konfiguriert sind
• Software, die AF_ALG-Sockets direkt öffnet
• kundenspezifische Integrationen, die aead, skcipher oder hash über die Kernel-Crypto-API verwenden

Mit anderen Worten: Für die meisten Unternehmens-Hosts hat das Blockieren des Moduls tendenziell geringe Auswirkungen. Bei Appliances, kundenspezifischen Krypto-Stacks oder stark optimierten Softwarepfaden sollten die Auswirkungen vor dem Rollout validiert werden.

Betriebliche Auswirkungen der Deaktivierung des Moduls

Das Blockieren des Moduls reduziert die Exposition sofort, bringt aber Kompromisse mit sich:

• Anwendungen, die von AF_ALG abhängen, starten möglicherweise nicht oder verlieren die kernelgestützte Krypto-Beschleunigung
• kundenspezifische Workloads können erst zur Laufzeit fehlschlagen, nicht beim Boot
• wenn das Modul bereits geladen ist, ist die Minderung erst nach einem erfolgreichen Entladen oder einem Neustart vollständig

Für Produktionsumgebungen ist der sicherere Ansatz, die Minderung in einem kontrollierten Wartungsfenster anzuwenden und kritische Anwendungen danach zu validieren.

Empfohlener dauerhafter Fix

Das Blacklisten des Moduls ist nur eine temporäre Minderung. Der dauerhafte Fix ist:

1. einen gepatchten Kernel installieren, der vom Distributionsanbieter bereitgestellt wird
2. den Host neu starten, sodass der neue Kernel tatsächlich geladen wird
3. validieren, dass der Host nicht mehr als betroffen gemeldet wird
4. erst dann entscheiden, ob die Modul-Blacklist bestehen bleiben soll

Zusätzliche empfohlene Maßnahmen:

• Patchen auf Hosts mit lokalen Benutzern, Containern oder Ausführung von nicht vertrauenswürdigem Code priorisieren
• AF_ALG-Socket-Erstellung mit seccomp in Containern und Pipelines einschränken, wo anwendbar
• überprüfen, wo afalg oder die Kernel-Crypto-API explizit verwendet wird
• Inventar der Kernel-Versionen und ausstehenden Neustarts pflegen
• CI/CD-Runner und Kubernetes-Knoten als hohe Priorität behandeln

Was das Skript prüft

Das Skript untersucht:

• Host-Hostname
• laufende Kernel-Version
• Betriebssystem über /etc/os-release
• Vorhandensein des Moduls algif_aead
• ob das Modul derzeit geladen ist
• ob das Modul durch eine modprobe-Regel blockiert ist
• ob der Host einen Neustart erfordert (/var/run/reboot-required)
• Status, der von Ubuntu Pro über pro fix CVE-2026-31431 --dry-run gemeldet wird, sofern verfügbar

Basierend darauf gibt es eine der folgenden Klassifizierungen zurück:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Klassifizierungslogik

Zusammenfassend:

• Wenn Ubuntu-Tools anzeigen, dass der Host nicht betroffen oder bereits behoben ist, wird der Status PATCHED_OR_NOT_AFFECTED.
• Wenn das Modul algif_aead im aktuellen Kernel nicht existiert, tendiert der Status zu LIKELY_NOT_VULNERABLE.
• Wenn das Modul existiert, aber blockiert und nicht geladen ist, wird der Status MITIGATED.
• Wenn Ubuntu anzeigt, dass der Host betroffen ist und das Modul geladen ist, wird der Status VULNERABLE_MODULE_LOADED.
• Wenn das Modul existiert und ladbar ist, der Patch-Status jedoch nicht bestätigt werden kann, wird der Status POTENTIALLY_VULNERABLE.

Anforderungen

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get für --update
• sudo bei Ausführung als Nicht-Root-Benutzer
• pro optional, um die Analyse auf Ubuntu anzureichern

Verwendung

Wenn die Skriptdatei check_cve_2026_31431.sh heißt:

Standardprüfung

Beispielausgabe:

JSON-Ausgabe

Beispiel:

Diese Ausgabe ist nützlich für Automatisierung, Asset-Inventar und Compliance-Pipelines.

Minderung

Der Modus --mitigate erstellt die Datei:

Mit folgendem Inhalt:

Danach versucht das Skript, das Modul aus dem Speicher zu entfernen mit:

Verwendung:

Wenn der Benutzer nicht root ist, versucht das Skript, sudo zu verwenden.

Update

Der Modus --update führt Folgendes aus:

Verwendung:

Dieser Modus versucht, kernelbezogene Pakete auf Debian- und Ubuntu-basierten Systemen zu aktualisieren. In anderen Umgebungen ist dieser Schritt möglicherweise nicht anwendbar.

Hilfe

Ausgabe:

Wichtige Einschränkungen

• Das Skript verwendet Heuristiken. Es beweist keine Ausnutzung; es schätzt Exposition und Minderungsstatus.
• Die Felder ubuntu_affected und fix_available hängen vom Vorhandensein des Befehls pro ab.
• Der Schritt --update verwendet Ubuntu- und Debian-orientierte Paketmuster und deckt möglicherweise nicht alle kundenspezifischen Kernel ab.
• Auf einigen Distributionen kann das Modul mit einem Verhalten existieren, das von den Erwartungen des Skripts abweicht.
• Das Blockieren des Moduls kann in einigen Umgebungen einen Neustart erfordern, um einen konsistenten Zustand zu gewährleisten.

Empfohlener Workflow

1. --check ausführen, um den Host zu bewerten.
2. Wenn das Modul verfügbar ist und kein Patch angewendet wurde, --mitigate ausführen.
3. --update ausführen oder das offizielle Vendor-Update anwenden.
4. Den Host bei Bedarf neu starten.
5. --check --json ausführen, um den endgültigen Zustand zu validieren und Nachweise zu behalten.

Hinweis

Zur besseren Veröffentlichungsklarheit sollte das Skript idealerweise einen beschreibenden Namen wie:

verwenden.

Credits

Material organisiert und veröffentlicht mit Anerkennung an SEC17.

Offizielle Website:

• https://sec17.com