SCTPhantom-Mitigation für Yandex Managed Kubernetes

Automatische Anwendung der Mitigation für die Schwachstelle CVE-2026-64564 (SCTPhantom) im Linux-Kernel auf allen Worker-Knoten des Yandex Managed Kubernetes Clusters.

Beschreibung der Schwachstelle

CVE-Kennung (CVE-ID): CVE-2026-64564

Link zum CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-64564

Ursprünglicher Bericht:

• Technischer Write-up (Tencent Zhuque Lab / Corvus AI): https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
• Öffentlicher PoC (LPE unter Debian 13, Kernel 6.12.95): https://github.com/ethanolgolf/CVE-2026-64564
• Upstream-Fix (mainline): Commit 9b2854f86f0b in net/sctp/sm_make_chunk.c

Kurzbeschreibung:

SCTPhantom ist ein Use-after-Free in dem Linux-Kernel-Subsystem SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061), das einem unprivilegierten lokalen Benutzer ermöglicht, Superuser-Rechte (root) zu erlangen.

Die Grundursache ist ein Identitätskonflikt bei der Verarbeitung des ASCONF-Chunks: Die Prüfung der DEL-IP-Operation erfolgt gegen die Quelladresse des IPv4-Pakets (S), während die weitere Verarbeitung den über den Address Parameter (L) gewählten transport verwendet. Dadurch passiert die geordnete Sequenz

[ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ]

die Prüfung und löscht transport(L), woraufhin die Wildcard-Operation DEL-IP 0.0.0.0 den bereits freigegebenen Zeiger als „gespeicherten Pfad" wiederverwendet. Infolgedessen bleiben asoc->peer.primary_path und asoc->peer.active_path hängende Zeiger auf den freigegebenen struct sctp_transport, und ein anschließender Aufruf von getsockopt(SCTP_STATUS) dereferenziert sie.

Die anfällige Logik wurde in Linux 2.6.25 eingeführt (2007, Commit 42e30bf3463c), ist also seit etwa 18 Jahren im Kernel vorhanden.

Angriff:

• erfordert keinen Fernzugriff – nur ein unprivilegiertes lokales Konto
• erfordert nicht CAP_NET_ADMIN und CAP_SYS_ADMIN, funktioniert mit aktivem Standard-Seccomp-Profil; ASCONF und AUTH werden pro Socket über SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED aktiviert, daher muss der Sysctl net.sctp.addip_enable nicht geändert werden
• ist ein funktionierendes Container-Escape-Primitive: Die Autoren erlangten in 6 von 8 Versuchen Host-Root; der letzte Schritt ist call_usermodehelper_exec(), das einen Prozess in den initialen Namespaces des Hosts startet
• endet bei fehlgeschlagener Ausnutzung „sauber", ohne kernel panic, was die Erkennung erschwert
• die Exploit-Kette verwendet vorhandenen Kernel-Code wieder (datenorientiertes commit_creds()), ohne Shellcode und klassisches ROP

Betroffene Technologien:

• Linux-Kernel, Subsystem net/sctp (Modul sctp), Verarbeitung von ASCONF in net/sctp/sm_make_chunk.c
• Modul sctp_diag (hängt von sctp ab), wird zur Inspektion von SCTP-Sockets verwendet

Die Schwachstelle ist nur ausnutzbar, wenn SCTP verfügbar ist: Wenn das Modul sctp nicht geladen und dessen Autoload blockiert ist, ist der Vektor nicht verfügbar.

Von den Autoren bestätigte Ziele (Root erlangt):

Distribution	Kernel
Research kernel	Linux 7.2-rc2
OpenCloudOS-family	6.6.119
Debian 13	6.12.95+deb13-amd64
Rocky Linux 9 / RHEL 9	5.14 vendor kernel (bei geladenem Modul sctp)
Ubuntu 24.04	6.8.0-134-generic

Korrigierte Kernel-Versionen:

Branch	Erste korrigierte Version	Stable-Fix
6.6.y	6.6.148	fedeb4468987
6.12.y	6.12.101	74e8f3e7114f
6.18.y	6.18.42	85aca407c560
7.1.y	7.1.6	d136b29bf91d
mainline	7.2-rc5	9b2854f86f0b

Vendor-Kernel können einen Backport des Fixes bei einer älteren Versionsnummer enthalten – die Kernel-Version allein ist kein hinreichendes Indiz für die Schwachstelle; orientieren Sie sich an den Advisories oder den Quellen des Vendors.

Angriffsvektor und Gefährdungsgrad gemäß CVSS v.4.0:

Basisscore: 8.5 (HIGH)

Vektor: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Was dieser Fix bewirkt

Der DaemonSet führt auf jedem Worker-Knoten des Clusters automatisch Folgendes aus:

1. Prüft den Status der Module – prüft, ob sctp und sctp_diag geladen sind und mit welchem refcnt. Die Prüfung ist bewusst passiv: Der DaemonSet öffnet keinen SCTP-Socket, bevor die Blacklist eingerichtet ist, um das Laden des Moduls auf einem Knoten, auf dem es noch nicht geladen ist, nicht auszulösen.
2. Prüft, ob SCTP auf dem Knoten verwendet wird – analysiert den refcnt des Moduls und die aktiven Einträge in /proc/net/sctp/assocs und /proc/net/sctp/eps. Kubernetes selbst nutzt SCTP nicht, aber eine benutzerdefinierte Workload kann protocol: SCTP in Service/Pod deklarieren.
3. Blockiert die verwundbaren Module – erstellt /etc/modprobe.d/blacklist-sctp.conf mit install- und blacklist-Regeln für sctp und sctp_diag.
4. Entlädt die Module – führt rmmod für sctp_diag und dann für sctp aus (die Reihenfolge ist wichtig: sctp_diag hängt von sctp ab). Wenn aktive SCTP-Verbindungen erkannt werden, wird das Entladen übersprungen, sofern nicht explizit FORCE_APPLY=true gesetzt ist.
5. Verifiziert die Mitigation – prüft, ob die Konfiguration vorhanden ist, ob modprobe sctp abgelehnt wird und ob das Erstellen eines SCTP-Sockets (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) nicht mehr möglich ist.
6. Überwacht den Zustand – prüft stündlich das Vorhandensein der Konfiguration, stellt sie bei Verlust wieder her und entlädt die Module erneut, falls sie wieder geladen wurden.

Wichtig: zwei mögliche Ausgänge auf dem Knoten

Die Mitigation besteht aus zwei unabhängigen Teilen, und auf einigen Knoten wird nur einer von ihnen angewendet.

1. Blacklist (wird immer zuverlässig angewendet). Nach der Erstellung von /etc/modprobe.d/blacklist-sctp.conf kann das Modul sctp nicht mehr geladen werden – weder automatisch bei socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) noch durch explizites modprobe. Dies schließt den Vektor auf Knoten, auf denen das Modul noch nicht geladen war (typischer Zustand: SCTP wird von Kubernetes nicht verwendet und nur bei Bedarf geladen).

2. Entladen des Moduls aus dem Speicher (nicht immer möglich). Wenn sctp bereits geladen ist, lässt es sich meist nicht entladen. Auf getesteten Yandex Managed Kubernetes-Knoten (Ubuntu 22.04, Kernel 5.15.0-181-generic) hat ein frisch geladenes und von niemandem verwendetes Modul sctp bereits refcnt=6 bei leerer Holder-Liste und leeren /proc/net/sctp/{assocs,eps}, und rmmod gibt ERROR: Module sctp is in use zurück. Der Zähler nimmt mit der Zeit nicht ab.

Daraus ergeben sich zwei Konsequenzen:

• refcnt ist kein Indikator für die SCTP-Nutzung – der DaemonSet gibt ihn nur informativ aus und entscheidet über das Entladen anhand der aktiven Einträge in /proc/net/sctp/assocs und /proc/net/sctp/eps.
• Auf einem Knoten, auf dem sctp bereits resident ist, meldet der DaemonSet ehrlich ⚠ mitigation applied PARTIALLY. Die Blacklist ist dort bereits aktiv (nach einem Neustart wird das Modul nicht zurückkehren), aber bis zum Neustart bleibt der Knoten verwundbar. Um den Vektor vollständig zu schließen, müssen solche Knoten neu gestartet oder die Node-Gruppe neu erstellt werden.

Solche Knoten nach dem Rollout finden:

kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'

Kompatibilität mit Workloads

Wichtig: Die Mitigation deaktiviert SCTP auf dem Knoten vollständig.