---
title: "Kernel-Lücke 'Copy Fail' (CVE-2026-31431)"
url: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-copy-fail'
markdown: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-copy-fail.md'
lang: de
date: '2026-04-30'
description: 'Linux-Kernel-Lücke Copy Fail (CVE-2026-31431) betrifft RHEL und Derivate: Privilege Escalation. Wie man patcht und ob man verwundbar ist.'
taxonomy:
  category:
    - blog
  tag:
    - linux
    - security
  archives_month:
    - apr_2026
  archives_year:
    - '2026'
---

[ Home ](https://www.linuxfabrik.ch/de)     [ Blog ](https://www.linuxfabrik.ch/de/blog)      Kernel-Lücke 'Copy Fail' (CVE-2026-31431)    

[CVE-2026-31431](https://access.redhat.com/security/cve/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"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-002) auf "Resolved" gesetzt, alle Fixes sind verfügbar. Die Lücke steht seit 2026-05-01 im [CISA-KEV-Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-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](https://forums.rockylinux.org/t/cve-2026-31431-copy-fail-linux-kernel-crypto-vulnerability/20375) (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](#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](https://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](https://access.redhat.com/security/cve/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](https://access.redhat.com/security/cve/CVE-2026-31431) und unsere [Mirror-Server](https://www.linuxfabrik.ch/de/leistungen/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](https://www.linuxfabrik.ch/de/leistungen/service-support) an und melde dich [bei uns](https://www.linuxfabrik.ch/de/kontakt).

 [ Vorheriger Beitrag](https://www.linuxfabrik.ch/de/blog/linuxfabrik-firewallfabrik-release-v1.0.0) [Nächster Beitrag ](https://www.linuxfabrik.ch/de/blog/kernel-luecke-dirty-frag)

#### Tags

  [ansible](https://www.linuxfabrik.ch/de/blog/tag:ansible) [checklistfabrik](https://www.linuxfabrik.ch/de/blog/tag:checklistfabrik) [cloud](https://www.linuxfabrik.ch/de/blog/tag:cloud) [datacenter](https://www.linuxfabrik.ch/de/blog/tag:datacenter) [event](https://www.linuxfabrik.ch/de/blog/tag:event) [firewallfabrik](https://www.linuxfabrik.ch/de/blog/tag:firewallfabrik) [graylog](https://www.linuxfabrik.ch/de/blog/tag:graylog) [icinga](https://www.linuxfabrik.ch/de/blog/tag:icinga) [lfops](https://www.linuxfabrik.ch/de/blog/tag:lfops) [linux](https://www.linuxfabrik.ch/de/blog/tag:linux) [monitoring-plugins](https://www.linuxfabrik.ch/de/blog/tag:monitoring-plugins) [news](https://www.linuxfabrik.ch/de/blog/tag:news) [nextcloud](https://www.linuxfabrik.ch/de/blog/tag:nextcloud) [security](https://www.linuxfabrik.ch/de/blog/tag:security) 

#### Archiv

- [2026](https://www.linuxfabrik.ch/de/blog/archives_year:2026)
- [2025](https://www.linuxfabrik.ch/de/blog/archives_year:2025)
- [2024](https://www.linuxfabrik.ch/de/blog/archives_year:2024)
- [2023](https://www.linuxfabrik.ch/de/blog/archives_year:2023)
- [2022](https://www.linuxfabrik.ch/de/blog/archives_year:2022)
- [2021](https://www.linuxfabrik.ch/de/blog/archives_year:2021)
- [2020](https://www.linuxfabrik.ch/de/blog/archives_year:2020)

#### Abonnements

 [ Atom](https://www.linuxfabrik.ch/de/blog.atom) [ RSS](https://www.linuxfabrik.ch/de/blog.rss)

---

## Navigation

- Parent: [Blog](https://www.linuxfabrik.ch/de/blog.md)
- Previous: [Kernel-Lücke 'Dirty Frag' (CVE-2026-43284)](https://www.linuxfabrik.ch/de/blog/kernel-luecke-dirty-frag.md)
- Next: [FirewallFabrik: der Nachfolger von Firewall Builder](https://www.linuxfabrik.ch/de/blog/linuxfabrik-firewallfabrik-release-v1.0.0.md)