DirtyDecrypt: Linux-Kernel-LPE im RxGK-Subsystem (CVE-2026-31635) mit öffentlichem PoC

TL;DR — 90 Sekunden

Was ist das Problem?

Der Bug sitzt im RxGK-Subsystem des Linux-Kernels. RxGK ist die GSS-API-basierte Sicherheits-Schicht für RxRPC, dem Netzwerk-Transport, den der Andrew File System Client (afs.ko) und einige verwandte verteilte Dateisysteme nutzen. Wer noch nie mit AFS in produktiver Umgebung gearbeitet hat, hält das Subsystem für eine historische Exotik; tatsächlich ist CONFIG_RXGK in allen Mainline-Linux-Builds und in den Rolling-Release-Distributionen Standardausstattung, weil die Aufnahme in den Kernel nichts darüber sagt, ob das Modul real geladen ist. Geladen wird es erst, wenn ein Userspace-Prozess auf den AFS-Codepfad zugreift — oder wenn ein lokaler Nutzer das Modul per modprobe lädt.

Die konkrete Fehlerstelle liegt in rxgk_decrypt_skb(), der Funktion, die ein eingehendes sk_buff (Socket-Buffer) auf der Empfangsseite entschlüsselt. In diesem Codepfad verarbeitet der Kernel Speicherseiten, die teilweise mit dem Page Cache anderer Prozesse geteilt sind — eine normale Optimierung in Linux, die durch Copy-on-Write geschützt wird: sobald eine Schreiboperation auf eine geteilte Seite erfolgt, wird vorher eine private Kopie angelegt, damit der Schreibzugriff nicht in die Daten eines anderen Prozesses durchschlägt. In rxgk_decrypt_skb() fehlt dieser Guard. Eine Entschlüsselungs-Operation schreibt direkt auf eine geteilte Page Cache-Seite, und der Schreibvorgang landet damit in einem Speicherbereich, der einem anderen, privilegierten Prozess gehört, oder, je nach Ausnutzungspfad, im Page Cache einer privilegierten Datei (zum Beispiel /etc/shadow, /etc/sudoers oder einer SUID-Binary).

V12 beschreibt den Bug in der eigenen Disclosure als „rxgk pagecache write due to missing COW guard in rxgk_decrypt_skb“. Das Team meldete den Fund am 9. Mai an die Kernel-Maintainer und bekam die Antwort, dass die Lücke bereits intern als Duplikat erkannt und gepatcht war. Will Dormann (CERT/CC, später Analygence) ordnet den V12-Bug technisch dem still gemergten Commit vom 25. April zu, der CVE-2026-31635 trägt. Ein formales CVE-Tracking-Label für „DirtyDecrypt“ als Alias existiert zu Redaktionsschluss nicht.

Bug-Klasse im Kontext der „Dirty“-Familie

Bug-typologisch reiht sich DirtyDecrypt in die Familie der jüngsten Linux-Kernel-LPEs ein, die alle auf subtilen Memory-Management-Schwächen sitzen: Dirty Frag (CVE-2026-43284 / CVE-2026-43500, behandelt im Bestandspost vom 10.05.2026), Fragnesia, Copy Fail (Referenz-Page UID 732, derzeit in CISA-KEV), Pack2TheRoot im PackageKit-Daemon. Das verbindende Element ist nicht das Modul, sondern die Bug-Klasse: Race Conditions oder fehlende Synchronisations-Garantien auf Page-Cache-Operationen, die mit hinreichend präzisem Timing zu einem privilegierten Schreibzugriff führen. DirtyDecrypt sitzt am Schnittpunkt aus Netzwerk-Subsystem und Page-Cache, was die Auslöse-Bedingung präziser macht als bei Copy Fail, aber den Ausnutzungs-Pfad nicht weniger gefährlich.

Wer ist betroffen?

Die Frage „bin ich betroffen“ lässt sich in zwei Sekunden auf der Kommandozeile beantworten — und beantwortet sich für die meisten DACH-Mittelstands-Plattformen mit „nein, aber Sie sollten trotzdem genauer hinsehen, wo Sie Rolling-Release-Kernel haben“.

Der für den Mittelstand relevanteste Befund liegt nicht in der ersten, sondern in der vorletzten Zeile: Entwickler-Workstations auf Fedora oder Arch sind in unserem Kundenkreis verbreitet, weil sie für Container-, Kubernetes- und KI-Tooling-Arbeit die natürliche Wahl sind. Genau diese Maschinen halten produktive kubectl-Kontexte, AWS-Profile mit Production-Rollen und SSH-Schlüssel zu Produktionssystemen vor. Ein lokaler Root auf einer SRE-Workstation ist operativ schmerzhafter als ein lokaler Root auf einem isolierten Build-Server.

Auswirkungen

Bei DirtyDecrypt ist die Frage „was geht damit theoretisch?“ weniger interessant als die Frage „was geht damit in einer realistischen Angriffskette?“. Theoretisch: vollständige Kompromittierung des Linux-Hosts, Lese-/Schreibzugriff auf alle Dateien, Persistenz, Container-Boundary-Bruch, je nach Hardening auch Kernel-Module-Loading. Realistisch hingegen verläuft die Kette in fast allen Fällen zweistufig.

Stufe eins ist der initiale Fuß auf dem Host. Den verschafft sich ein Angreifer in der Regel nicht mit DirtyDecrypt — die Lücke ist eine LPE, keine RCE. Eingang findet er über die üblichen Wege: kompromittierte SSH-Credentials (Stuffing, Phishing, durchgesickerte Keys), eine angreifbare öffentlich zugängliche Anwendung (PHP-Plattform mit Upload-Lücke, Sylius mit auth-Bug, alter nginx-Worker), oder bei Container-Plattformen ein kompromittiertes Pod-Image im Cluster. In jedem dieser Fälle landet der Angreifer mit einer unprivilegierten Identität auf einem Linux-Userspace.

Stufe zwei ist DirtyDecrypt. Der Angreifer prüft per grep RXGK /boot/config-$(uname -r), ob das Subsystem aktiv ist, lädt das rxrpc-Modul falls nötig (modprobe rxrpc), führt den V12-PoC aus und hat Root. Auf einer Kubernetes-Worker-Node ist „Root auf dem Host“ gleichbedeutend mit „Zugang zu allen Pods, allen Container-Runtime-Sockets, allen Kubernetes-Secrets, die auf diesem Knoten gemountet sind“. Auf einer SRE-Workstation ist „Root“ gleichbedeutend mit „Zugang zu jedem Cloud-Profil, jedem kubeconfig, jedem SSH-Agent, jedem GPG-Schlüssel im Keyring“.

In CVSS-Sprache ist das eine Local-Privilege-Escalation mit AC:L/PR:L/AI:N/Vertraulichkeit-Integrität-Verfügbarkeit:H — typischerweise im Bereich 7,8–8,1. Der Score ist hier weniger aussagekräftig als der Kontext. CISA hat am 8. Mai die Schwester-Lücke „Copy Fail“ in den KEV-Katalog aufgenommen, mit Patch-Frist 15.05.2026 für Federal Civilian Executive Branch Agencies, ausdrücklich weil das Federal-Risiko-Profil bei einer LPE im Kernel höher ist als der CVSS-Score impliziert. Wer im DACH-Mittelstand auf NIS-2-Pflicht-Liste steht, sollte die CISA-Einstufung als Indikator nehmen, nicht den CVSS-Score.

Mitigation / Sofortmaßnahmen

Reihenfolge: erst patchen (wenn möglich), dann Workaround, dann strukturell die Container-Host-Strategie sortieren.

Pfad 1 — Kernel-Patch ziehen

# Fedora / Fedora CoreOS
sudo dnf upgrade --refresh kernel kernel-core kernel-modules
sudo systemctl reboot
uname -r
# Ziel: Kernel mit Build-Datum nach 25.04.2026 oder explizit CVE-2026-31635 in den Patch-Notes

# Arch Linux / Arch-basierte Hosts
sudo pacman -Syu linux linux-headers
sudo systemctl reboot
uname -r

# openSUSE Tumbleweed
sudo zypper dup
sudo systemctl reboot

# Ubuntu Mainline-PPA (falls genutzt)
sudo apt update
sudo apt upgrade linux-image-generic linux-headers-generic
sudo systemctl reboot

Vor dem Reboot prüfen, ob das rxrpc-Modul live ist und auf welchen Files das afs-Kernel-Modul-Lock sitzt — sonst hängt ein Mount nach dem Reboot fest:

lsmod | grep -E "(rxrpc|afs)"
fuser -m /afs 2>/dev/null

Pfad 2 — Workaround (kein Patch verfügbar)

Wer einen Patch nicht heute einspielen kann (Wartungsfenster nicht da, Vendor-Kernel hängt nach), entlädt die betroffenen Module und blacklistet sie, bis das Update sitzt. Achtung: das bricht IPsec-VPN und AFS.

# 1. Module-Blacklist anlegen
sudo tee /etc/modprobe.d/dirtydecrypt-mitigation.conf > /dev/null <<'EOF'
# Temporary mitigation for DirtyDecrypt / CVE-2026-31635
# Remove this file after kernel patch is applied
blacklist esp4
blacklist esp6
blacklist rxrpc
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# 2. Aktive Module entladen (vorher prüfen, ob nichts aktiv darauf läuft)
sudo modprobe -r esp4 esp6 rxrpc 2>&1 | tee /tmp/modprobe-remove.log

# 3. Module-Cache und Page-Cache leeren
sudo depmod -a
sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

# 4. Verifizieren, dass die Module nach Reboot nicht geladen werden
lsmod | grep -E "(esp4|esp6|rxrpc)" && echo "WARN: module still loaded" || echo "OK: blacklisted"

Achtung: Der Workaround bricht IPsec-VPN-Verbindungen (StrongSwan, libreswan, Algo, WireGuard nicht — der nutzt einen anderen Pfad) und das AFS-Distributed-Filesystem. In Enterprise-Umgebungen mit Site-to-Site-VPN ist das ein operativer Vorfall, nicht eine harmlose Vorsichtsmaßnahme. Erst patchen, dann Workaround zurücknehmen.

Pfad 3 — Container-Host-Strategie für Kubernetes

Wer Kubernetes-Worker auf Rolling-Release-Distros fährt, sollte heute eine Architekturentscheidung treffen. Die schnellste Mitigation ist nicht der Kernel-Patch auf jedem einzelnen Knoten, sondern der Wechsel auf eine deklarative Host-Strategie:

# Talos Linux Worker-Pool prüfen
talosctl --nodes worker-01 version
# Wenn die Talos-Version vor 1.10.x liegt und einen Custom-Kernel-Build hat:
# Worker per `talosctl upgrade --image ghcr.io/siderolabs/installer:v1.10.x` heben

# Flatcar Worker-Pool prüfen
ssh worker-01 cat /etc/os-release | grep VERSION
# Flatcar zieht Kernel-Patches über das automatisierte OS-Update;
# Reboot-Window via Kured oder Karpenter steuern

# Bottlerocket Worker-Pool prüfen
aws ssm send-command --instance-ids i-... \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["uname -r"]'

Im normalen Kubernetes-Betrieb sollte imagePullPolicy: Always, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, runAsNonRoot: true Standard sein. Wer diese Defaults noch nicht erzwingt, hat ein größeres Problem als DirtyDecrypt — Pod-Security-Standards (restricted-Profil) sollten clusterweit aktiv sein, und genau diese Lücke ist ein Anlass, das nachzuziehen.

Detection / Prüfung

Eine spezifische Detection für eine DirtyDecrypt-Ausnutzung ist mit klassischen Logs schwierig: der Exploit läuft im Userspace und schreibt über einen Kernel-Pfad in den Page Cache eines anderen Prozesses, ohne dass dabei ein execve oder ein verdächtiger Syscall auffällt. Die Detection sitzt an drei Stellen.

Versions-Sweep (Inventur, kein Echtzeit-Signal)

# Über alle Hosts iterieren (ansible / mssh / clusterssh)
for host in $(cat hosts.txt); do
    ssh "$host" '
        echo "=== $(hostname) ==="
        uname -r
        zcat /proc/config.gz 2>/dev/null | grep RXGK || grep RXGK /boot/config-$(uname -r) 2>/dev/null
        lsmod | grep -E "(rxrpc|afs|esp4|esp6)"
    '
done

Falco-Rule für rxgk-Module-Load

- rule: rxgk_module_loaded_on_production_host
  desc: rxrpc kernel module loaded on a production host outside the maintenance window (heuristic for DirtyDecrypt exploit attempt)
  condition: >
    spawned_process and
    proc.name = "modprobe" and
    proc.cmdline contains "rxrpc"
  output: >
    rxrpc module load detected (proc=%proc.name cmdline=%proc.cmdline user=%user.name pid=%proc.pid host=%container.hostname)
  priority: WARNING
  tags: [cve-2026-31635, dirtydecrypt, linux-kernel, lpe]

- rule: unexpected_rxgk_decrypt_skb_activity
  desc: Unusual kernel activity around rxgk decryption path
  condition: >
    evt.type = "syscall" and
    syscall.name in ("setresuid", "setreuid", "setuid") and
    proc.aname[1] != "systemd" and
    user.uid != 0 and
    fd.name contains "/proc/self/status"
  output: >
    Unprivileged process attempting UID change (proc=%proc.name pid=%proc.pid parent=%proc.aname[1])
  priority: NOTICE
  tags: [linux-lpe, post-exploitation]

Tetragon-TracingPolicy als Alternative

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-rxgk-module-load
spec:
  kprobes:
  - call: "do_init_module"
    syscall: false
    args:
    - index: 0
      type: "module"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "rxrpc"
        - "rxgk"
      matchActions:
      - action: Sigkill

Die Sigkill-Action ist aggressiv — in produktiven Umgebungen erst auf Override mit Logging stellen, validieren, dann hochstufen.

Betreiberempfehlung

Operational Decision Block

• Sofort mitigieren, wenn … Sie Kubernetes-Worker auf Fedora CoreOS Rawhide, Arch-basierten Custom-Builds oder bleeding-edge Talos-Nightly fahren, oder wenn Entwickler:innen mit privilegierten Cloud-Profilen auf Fedora-/Arch-/Tumbleweed-Workstations arbeiten. Patch heute, Modul-Blacklist als Backup.
• Wartungsfenster möglich, wenn … Ihre Hosts auf Debian Stable, RHEL, Ubuntu LTS oder Talos Stable laufen und CONFIG_RXGK ausgeschaltet ist. Patch beim nächsten Kernel-Cycle, kein Sondertermin nötig — aber Inventur über alle Hosts trotzdem fahren, damit Sie das wissen statt vermuten.
• Reine Bare-Metal-Stable-Stacks, wenn … Sie keinen Rolling-Release-Kernel im Einsatz haben und keine Container-Plattform betreiben. Standard-Patch-Cycle reicht.

Mittelstand

Im DACH-Mittelstand ist DirtyDecrypt für die Mehrheit der reinen Web-Plattformen kein Akut-Thema, weil die Standard-Hosting-Stacks auf Debian-Stable-Linien sitzen. Akut wird es an zwei Stellen: erstens auf den Entwickler-Workstations, die in der Regel Fedora oder Arch fahren, und zweitens auf Kubernetes-Clustern, sofern die Worker auf Rolling-Distros laufen. Beides ist häufiger, als man denkt — die Frage „auf welcher Distro läuft euer dev-cluster?“ ergibt in Kundengesprächen oft „Fedora CoreOS Rawhide, weil wir die neuesten Container-Features brauchen“. Genau diese Cluster brauchen heute den Patch oder den Workaround.

Enterprise / Kubernetes

Auf Kubernetes ist die operative Frage nicht „patchen wir die Worker“, sondern „wie schnell rotiert unser Node-Pool“. Wer Karpenter oder einen Cluster-Autoscaler mit kurzem TTL und automatischem Node-Image-Refresh fährt, bekommt den Patch innerhalb von Stunden, sobald das gepatchte Worker-Image im Image-Registry liegt. Wer Quartal-Pinned-AMIs verwendet, hat ein längeres Fenster — und braucht in dieser Zeit die Pod-Security-Defaults als Sicherheitsnetz. Klar empfehlenswert: restricted-Pod-Security-Standard clusterweit erzwingen, allowPrivilegeEscalation: false als Default, und für privilegierte Workloads (CSI-Driver, CNI-Plugins, Monitoring-Agents) eine explizite, dokumentierte Ausnahme statt einer schweigenden Toleranz.

Deklarative Stacks (NixOS / Talos / Flatcar / Bottlerocket)

Talos Linux ist der Pfad mit dem kleinsten Sorgenfaktor in dieser Lage: der gesamte Worker-Host ist ein deklaratives Image, CONFIG_RXGK ist im Talos-Kernel-Konfig auskonfigurierbar, der Patch landet über das normale Image-Upgrade. Flatcar ist analog. NixOS-Nutzer (in Plattformteams gelegentlich anzutreffen) ziehen den Patch über eine Pin-Erhöhung im Nix-Flake und einen Rebuild. Bottlerocket, eines der saubersten Worker-OS-Konzepte am Markt, hat RxGK in der Standardkonfiguration ohnehin auskonfiguriert — und auch wer in dieser Welt arbeitet, sollte das Vorfall-Pattern dokumentieren, weil es das Pattern für die nächste „Dirty“-Variante in zwölf Monaten sein wird.

Was wir konkret getan haben

Wir haben heute Morgen die V12-Disclosure gelesen und auf den eigenen Plattformen den Patch-Sweep ausgerollt — auf der Moselwal-Infrastruktur und den drei Kunden-Clustern, die wir aktiv betreuen.

Erstens haben wir den Versions-Sweep gefahren: auf den Linux-Hosts (Bare-Metal-Server, Kubernetes-Worker) per Ansible-Playbook, auf den NixOS-basierten Hosts über die Flake-Evaluation. Die Entwickler-Workstations bei Moselwal laufen auf macOS, sind von der Linux-Kernel-LPE direkt nicht betroffen und fielen damit aus dem Sweep heraus. Ergebnis auf der Linux-Seite: ein Kubernetes-Worker-Pool auf Talos 1.10-stable (RxGK auskonfiguriert, nicht betroffen), die restlichen Hosts auf Debian Bookworm beziehungsweise Bottlerocket (beide auskonfiguriert). Kein Treffer im Sweep — was nicht Glück ist, sondern das Ergebnis einer deklarativen Worker-OS-Strategie, die wir nach Copy Fail im April konsequent durchgezogen haben.

Zweitens haben wir auf den Hosts, auf denen ein Update sinnvoll war, die Patches eingespielt: per Ansible-Rollout für die imperativ verwalteten Server, per NixOS-Flake-Bump und Rebuild für die deklarativ verwalteten. Verifiziert haben wir nach Reboot per uname -r und gegen die CVE-2026-31635-Patch-Notes.

Drittens haben wir die Falco-Rule oben in unsere zentrale Regel-Bibliothek übernommen, mit Priority WARNING und Routing in den Slack-#sec-events-Channel. Eine zusätzliche Tetragon-Policy wäre theoretisch die schärfere Alternative auf Kernel-Ebene; wir haben sie auf den Clustern, die Tetragon laufen lassen, im Override-Modus ausgerollt, nicht im Sigkill-Modus, weil ein erstes False-Positive bei modprobe rxrpc durchaus aus einem legitimen Operations-Skript kommen kann.

Was wir bewusst nicht getan haben: den Modul-Blacklist-Workaround flächendeckend ausgerollt. Bei Moselwal ist IPsec aktuell nicht im Einsatz, eine Blacklist von esp4/esp6 hätte uns nichts gebrochen — sie wäre aber als Default eine Linie, die ein:e Kolleg:in in einem späteren Setup-Schritt unbemerkt rückgängig macht, sobald ein VPN-Anwendungsfall auftaucht. Patchen war hier der saubere Weg; der Workaround bleibt eine dokumentierte Notfall-Option für Hosts, bei denen Patch heute nicht geht.

Architektonisch sitzt unter dieser Episode das gleiche Muster wie bei Copy Fail und Dirty Frag im letzten Quartal: die operative Sicherheit eines Kubernetes-Clusters hängt nicht am einzelnen Pod-Manifest, sondern an der Frage, ob die Worker-Hosts auf einer Distribution laufen, die deklarativ und reproduzierbar gebaut wird. Talos, Flatcar, Bottlerocket gehen den Weg, ein altmodisches Server-Linux mit fünf Admins und einem Bastelkernel geht den anderen Weg. Wer die zweite Welt noch fährt, sollte spätestens nach DirtyDecrypt die Migration in die erste planen.

Fazit

DirtyDecrypt zwingt zu zwei Entscheidungen am gleichen Tag. Die taktische Entscheidung ist trivial: heute patchen, wo Rolling-Release-Kernel im Spiel ist; heute Inventur fahren, wo unklar ist; heute den Workaround stehen lassen für Hosts, bei denen Patch nicht geht. Die strategische Entscheidung ist die unangenehmere: ob die Worker-Distribution Ihrer Kubernetes-Cluster und die Distribution Ihrer SRE-Workstations zu der Art „Bastelkernel mit fünf Admins“ oder zu der Art „deklarativ gebautes Worker-OS“ gehören soll. Die „Dirty“-Familie der Linux-Kernel-LPEs in 2026 ist die empirische Antwort auf die Frage, warum die zweite Welt strukturell sicherer ist als die erste.

Die Frage lautet nicht, ob die nächste Kernel-LPE kommt. Sie lautet, ob Ihre Worker-Knoten so gebaut sind, dass die nächste Lücke sie nicht erneut auf dem falschen Fuß erwischt.

Dieser Beitrag spiegelt unsere technische Einschätzung. Er ersetzt keine Datenschutz-Folgenabschätzung und keine Rechtsberatung zu konkreten NIS-2-Meldepflichten.