Copy Fail technisch: AF_ALG, splice und Page Cache hinter CVE-2026-31431

April 29, 2026

Technische Illustration von AF_ALG, splice und Page Cache bei Copy Fail

Copy Fail, CVE-2026-31431, ist eine lokale Rechteausweitung im Linux-Kernel. Kurz gesagt kombiniert die Schwachstelle AF_ALG, splice(), das Kryptografie-Template authencesn und eine In-place-Optimierung in algif_aead, sodass ein kontrollierter 4-Byte-Schreibvorgang in den Page Cache möglich wird. Für Sicherheitsteams ist die nüchterne Beschreibung entscheidend: Es handelt sich um eine Grenzverletzung zwischen Scatterlists, die nie gemeinsam ein schreibbares Ziel hätten bilden dürfen.

Der kritische Teil ist AF_ALG, die Socket-Schnittstelle, die Kryptografie-Primitiven des Kernels für Userspace zugänglich macht. Mit splice() kann Userspace Daten aus einer Datei über eine Pipe bewegen, ohne jedes Byte zu kopieren. Dabei kann der Kernel Referenzen auf Page-Cache-Seiten behalten. Werden diese Seiten in eine Scatterlist verkettet, die das Kryptografie-Subsystem als Ziel behandelt, entsteht die gefährliche Bedingung.

Nach der Analyse von Xint Code verwendet authencesn einen Teil des Zielbuffers als temporären Arbeitsbereich, um ESN-bezogene Bytes umzuordnen. Unter den ursprünglichen Annahmen war dieses Verhalten nachvollziehbar. Gefährlich wurde es durch die Kombination mit dem AF_ALG-AEAD-In-place-Pfad, der Jahre später eingeführt wurde. Der temporäre Schreibvorgang verlässt die legitime Region und erreicht Seiten, die die Speicherkopie einer lesbaren Datei darstellen.

Warum der Page Cache den Impact verändert

Der Page Cache ist keine private Kopie des Angreiferprozesses. Er ist die Speicherdarstellung, die auch andere Systempfade lesen können. Gehört diese Kopie zu einem Setuid-Binary, kann eine temporäre Änderung im Speicher die Ausführung beeinflussen, ohne die Datei auf der Festplatte zu ändern. Deshalb reichen Prüfungen, die nur die physische Datei betrachten, für die Impact-Bewertung nicht aus.

Der gemeldete Schreibvorgang ist klein: 4 Bytes pro Operation. Größe allein bestimmt jedoch keine Schwere. Eine kleine, zuverlässige und wiederholbare Primitive kann ausreichen, wenn das Ziel sensibel ist. Der technische Kern von Copy Fail liegt in Kontrolle, Zuverlässigkeit und Portabilität über betroffene Kernel und Distributionen hinweg.

Das erklärt auch die Severity-Debatte. Die Schwachstelle erfordert lokale Ausführung und liefert keinen initialen Remote-Zugriff. Daher stufen mehrere Anbieter sie als mittel oder moderat ein. In Multi-Tenant-, CI-, Container- und Sandbox-Umgebungen ist die Grenze zwischen “lokal” und “kritisch” jedoch dünn: Lokale Codeausführung ist dort genau das angebotene Modell.

Die Korrektur

Die zentrale Korrektur stellt algif_aead wieder auf Out-of-place-Betrieb um. Statt Quelle und Ziel über eine kombinierte Struktur mit verketteten Page-Cache-Seiten zu teilen, trennt der Fix Eingabe- und Ausgabe-Scatterlists. Damit verschwindet die Bedingung, durch die der temporäre authencesn-Schreibvorgang dateibasierte Speicherseiten erreichen konnte.

Für Betreiber heißt das: Der Kernel der Distribution muss auf eine Version aktualisiert werden, die den Fix enthält. Manuelles Portieren einzelner Commits ist nur sinnvoll, wenn ein Team seinen eigenen Kernel pflegt und validiert. In normalen Flotten erfolgt die Remediation über Vendor-Pakete, AMIs, Basisimages oder den verwalteten Kernel des Cloud-Anbieters.

Als temporäre Mitigation empfiehlt die Copy-Fail-Seite, algif_aead zu deaktivieren oder die Erstellung von AF_ALG-Sockets für nicht vertrauenswürdige Workloads etwa mit seccomp zu blockieren. Das ist als Flächenreduktion sinnvoll, besonders für Runner und Sandboxes, muss aber getestet werden. Einige Embedded- oder Crypto-Offload-Konfigurationen können AF_ALG explizit nutzen.

Defensiver Checklist

Erstens: Inventarisiere reale Kernel, nicht nur Distributionen. Kernelversionen, Backports und Cloud-Builds sind wichtiger als Produktnamen. Zweitens: Identifiziere Hosts, auf denen Benutzer, Container oder CI-Jobs einen Kernel teilen. Diese Systeme haben Vorrang vor Ein-Benutzer-Servern.

Drittens: Prüfe, ob Sandbox-Regeln unnötige Socket-Familien blockieren. Viele Workloads benötigen AF_ALG nie. Wenn ein System fremden Code ausführt, reduziert das Blockieren ungenutzter Flächen auch über diesen Vorfall hinaus das Risiko. Viertens: Trenne Runner für externen Code und verwende privilegierte Hosts nicht für Pipelines mit niedrigem Vertrauen.

Fünftens: Validierung erfolgt gegen Vendor-Advisories. Die öffentliche Diskussion enthält nützliche Details, aber auch Fehler und Abweichungen, darunter die diskutierte Nennung einer nicht existierenden RHEL-Version. Für Change Management zählen offizielle Tracker und ein dokumentierter Plattformstatus.

Was der Patch nicht löst

Der Patch beseitigt nicht das Grundproblem, nicht vertrauenswürdigen Code auf gemeinsam genutzten Kernels auszuführen. Er ersetzt keine starke Isolation, Syscall-Kontrolle, Tenant-Trennung oder Rotation von Basisimages. Die technische Lehre ist breiter: In-place-Optimierungen mit Referenzen unterschiedlicher Herkunft müssen besonders geprüft werden, wenn Zero-copy-Pfade aus Userspace existieren.

Plattformteams sollten Regressionstests rund um splice(), Page Cache, Kryptografie-APIs für Userspace und Sandboxes mit selten genutzten Syscalls prüfen. Copy Fail zeigt, wie eine lokal sinnvolle Entscheidung gefährlich werden kann, wenn ein anderes Subsystem Jahre später das Speichermodell verändert.

Das Fazit ist Priorisierung statt Panik. Wo ein potenzieller Angreifer bereits lokalen Code ausführen kann, ist eine zuverlässige lokale Rechteausweitung kein Nebenthema. Sie ist ein Bruch der Vertrauensgrenze.