Überspringen zum Hauptinhalt

„Dirty Frag“ und andere Probleme in Amazon-Linux-Kerneln

Bulletin-ID: 2026-027-AWS
Geltungsbereich: AWS
Inhaltstyp: Wichtig (erfordert Aufmerksamkeit)
Datum der Veröffentlichung: 07.05.2026, 19:45 Uhr PDT
Änderungsdatum: 13.05.2026 13:30 Uhr PDT
 

⚠️Dies ist ein fortlaufendes Problem. Die Informationen können sich ändern. Die aktuellsten Patching-Informationen finden Sie in unserem Sicherheitsbulletin (ID: 2026-030-AWS).


Beschreibung:

Amazon ist einer Reihe von Problemen im Linux-Kernel bekannt (CVE-2026-43284), die mit dem ursprünglichen Problem zusammenhängen (CVE-2026-31431). Diese allgemein als „DirtyFrag“ bezeichneten Probleme sind in einer Reihe von ladbaren Modulen, vorhanden. Dazu gehören das Modul xfrm_user/esp4/esp6. Auf Systemen, auf denen nicht privilegierte Benutzer Sockets direkt oder über CAP_NET_ADMIN erstellen können oder auf denen die Erstellung von nicht privilegierten Benutzer-Namespaces (user+net) möglich ist, kann ein Akteur Zugriff auf den Kernel-Speicher erlangen und so seine Berechtigungen erweitern.

Für die betroffenen Services ist eine Aktion des Kunden erforderlich

Amazon Linux: Betroffen sind die Amazon-Linux-Kernel 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 und 6.18. AWS hat Updates für Amazon Linux veröffentlicht, die dieses Problem beheben. Kunden sollten unbedingt die neuesten Kernel-Updates installieren. Wir empfehlen, im Amazon Linux Security Center (ALAS) nach aktuellen Informationen zu diesem Problem zu suchen.

Wir empfehlen Kunden, die für ihre Umgebung verfügbaren Kernel-Updates zu installieren. Um bekannte Vektoren zu entschärfen, ohne Kernel-Updates anwenden zu müssen, sollten Kunden die folgenden Maßnahmen ergreifen:

  1. Überprüfen Sie anhand des folgenden Befehls, ob die betroffenen Module auf dem Host geladen sind:

        lsmod | grep -E "esp4|esp6|rxrpc"

    Wenn eines der betroffenen Module in der Ausgabe aufgeführt ist, sind diese Module derzeit geladen. Ist die Nutzung dieser Module unerwartet, führen Sie die folgenden Befehle aus und starten Sie dann das System neu. Handelt es sich um eine bekannte Nutzung, ziehen Sie andere Abhilfemaßnahmen in Betracht.

  2. Deaktivieren Sie das zukünftige Laden der betroffenen Module einzeln anhand der folgenden Befehle:

        echo 'install esp4 /bin/false' >> /etc/modprobe.d/cve-copyfail2.conf
        echo 'install esp6 /bin/false' >> /etc/modprobe.d/cve-copyfail2.conf
        echo 'install rxrpc /bin/false' >> /etc/modprobe.d/cve-copyfail2.conf

    Wenn die betroffenen Module derzeit nicht geladen sind, deaktivieren Sie alternativ das Laden aller zusätzlichen Kernel-Module anhand des folgenden Befehls:

        sysctl -w kernel.modules_disabled=1

    Beachten Sie, dass diese Änderung bis zum nächsten Neustart dauerhaft gültig ist.

    Um den für Namespaces spezifischen Vektor zu entschärfen, deaktiviert der folgende Befehl die Option zum Erstellen dieser Namespaces:

        sysctl -w user.max_user_namespaces=0

Kunden, die die oben genannten Module verwenden, sollten Ihre Umgebung auf ungewöhnliche Ausführungen von „setuid“ überwachen. Weitere Informationen zu „Copyfail v1“ finden Sie in unserem Sicherheitsbulletin.

Weitere Informationen werden in unserem Sicherheitsbulletin (ID: 2026-030-AWS) veröffentlicht, sobald Updates verfügbar sind.

Sicherheitsbulletins zu ähnlichen Themen – Varianten von copy.fail:

  1. Sicherheitsbulletin 2026-029-AWS – CVE-2026-43284 (auch als „Fragnesia“ bekannt)
  2. Sicherheitsbulletin 2026-026-AWS – CVE-2026-31431 (auch als „copy.fail“ bekannt)

Referenzen:


Bei Fragen oder Bedenken zum Thema Sicherheit senden Sie bitte eine E-Mail an aws-security@amazon.com.