Kernel-Lücke 'Copy Fail' (CVE-2026-31431)

linux security

CVE-2026-31431 ist eine lokale Privilege Escalation im Linux-Kernel-Crypto-API. Red Hat klassifiziert sie als Important (CVSS 7.8). Betroffen sind RHEL 8, 9 und 10 (kernel und kernel-rt) sowie OpenShift Container Platform 4. Bis der Kernel-Patch eingespielt ist, gilt die offizielle Boot-Parameter-Mitigation, und die sollte auf jedem RHEL-Host sofort gesetzt werden.

Update 2026-05-13: Red Hat hat das Bulletin RHSB-2026-002 "Copy Fail" auf "Resolved" gesetzt, alle Fixes sind verfügbar. Die Lücke steht seit 2026-05-01 im CISA-KEV-Catalog, aktive Ausnutzung ist damit offiziell bestätigt.

Update 2026-05-06: Patches sind unterwegs. Red Hat hat die offiziellen RHSAs um den 2026-05-04 / 2026-05-05 publiziert. Rocky Linux 8, 9 und 10 zieht laut Rocky-Linux-Forum (Post 65, 2026-05-06 06:42 UTC) innerhalb von 24 bis 48 Stunden über die regulären BaseOS-Mirror nach. Vor dem Update kurz prüfen:

$ sudo dnf check-update kernel
$ sudo dnf upgrade kernel
$ sudo systemctl reboot

Wer noch auf der Boot-Parameter-Mitigation sitzt, kann nach erfolgreichem Update neu starten und die Mitigation zurückrollen (siehe Patch einspielen).

Worum es geht

Im algif_aead-Modul wurde eine fehlerhafte In-Place-Operation eingeführt: Quell- und Ziel-Datenmappings unterscheiden sich. Über AF_ALG-Sockets kann ein lokaler unprivilegierter Userspace-Prozess das ausnutzen und Root-Rechte erlangen. Wir haben die Lücke auf Rocky Linux 9 und 10 verifiziert; in Container-Setups gelingt zusätzlich der Ausbruch auf den Host.

Eckdaten:

  • Red Hat-Public: 2026-04-22, Severity Important, CVSS v3 Vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
  • Forscher-Disclosure: 2026-03-29 (Xint Code, copy.fail)
  • Affected laut Red Hat: RHEL 8, 9, 10 und OpenShift Container Platform 4
  • Not affected: RHEL 6, 7 ("Vulnerable Code not Present")

Bin ich betroffen?

Ein Kernel-Config-Check deckt alle Distros ab:

$ grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
# =y    => builtin im Kernel (RHEL und kompatible)
# =m    => ladbares Modul (Debian, Ubuntu, viele andere)
# leer  => nicht kompiliert, nicht betroffen

Bei =m zusätzlich, ob das Modul gerade geladen ist:

$ lsmod | grep algif_aead

Bei =y ist lsmod kein Indikator, weil das Modul permanent Teil des Kernels ist. Wer aktiv AF_ALG-Sockets nutzt (selten, eher Custom-Crypto-Stacks):

$ sudo lsof 2>/dev/null | grep AF_ALG
$ ss -xa | grep -i alg

Mitigation auf RHEL und kompatiblen Distros

Auf RHEL, Rocky Linux, AlmaLinux, CentOS Stream und Oracle Linux ist algif_aead builtin. Modprobe-Blacklists greifen nicht. Red Hat blockiert stattdessen den Initcall der betroffenen Funktion beim Boot:

$ sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
$ sudo systemctl reboot

Eine der drei Varianten wählen, nicht kombinieren:

  • initcall_blacklist=algif_aead_init: nur den AEAD-Pfad sperren (Red Hats Empfehlung)
  • initcall_blacklist=af_alg_init: das gesamte AF_ALG-Interface deaktivieren
  • initcall_blacklist=crypto_authenc_esn_module_init: nur den konkret betroffenen Algorithmus

Red Hat weist auf mögliche Performance-Einbussen bei Anwendungen hin, die das Kernel-Crypto-API nutzen. Originaltext im Red Hat-Statement zu CVE-2026-31431.

Verifikation nach dem Reboot:

$ cat /proc/cmdline | grep initcall_blacklist
$ dmesg | grep -i initcall

Rollback, sobald der Kernel-Patch eingespielt ist:

$ sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
$ sudo systemctl reboot

Mitigation auf Distros mit ladbarem Modul

Für Hosts mit =m (z.B. Debian, Ubuntu) reicht eine modprobe-Sperre, bis der Kernel-Patch verfügbar ist:

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

Validierung:

$ lsmod | grep algif_aead              # leer
$ sudo modprobe -v algif_aead          # "install /bin/false" und Fehler

Die Abschaltung ist auf typischen Systemen unkritisch: dm-crypt/LUKS, kTLS, IPsec, OpenSSL/GnuTLS/NSS in Standard-Builds, SSH und das Kernel-Keyring-Crypto nutzen AF_ALG nicht. Custom-Crypto-Stacks (zum Beispiel OpenSSL mit afalg-Engine) vorher gegenchecken.

Container-Hosts

Der Bug ermöglicht in Container-Setups den Ausbruch auf den Host. Kernel-Module gehören zum Host und Container teilen den Kernel, deshalb muss die Mitigation zwingend auf den Host gesetzt werden. Eine reine Container-seccomp-, SELinux- oder AppArmor-Policy reicht nicht.

Patch einspielen

Sobald die Distro den Fix ausliefert:

# RHEL und kompatible
$ sudo dnf check-update kernel

# Debian / Ubuntu
$ sudo apt update && apt list --upgradable | grep linux-image

Update einspielen, neu starten, danach die Mitigation zurücknehmen (Rollback-Block oben für RHEL, beziehungsweise sudo rm /etc/modprobe.d/disable-algif.conf plus Reboot für ladbare Module).

Patches sind verfügbar (siehe Update-Hinweis am Anfang). Den Red Hat-CVE-Eintrag und unsere Mirror-Server für Folge-Errata im Auge behalten.

Wir helfen dir

Brauchst du Unterstützung beim Patchen oder Härten deiner Linux-Server? Schau dir doch mal unsere Service & Support-Modelle an und melde dich bei uns.

Vorheriger Beitrag Nächster Beitrag

DE · EN