Linux-Kernel-Sammelwelle 28.–30.05.2026: CVE-2026-46227 SCTP `SCTP_SENDALL` Type-Confusion als unprivilegierte LPE-Primitive in einer Welle von 117 CVEs

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Eine ungewöhnliche Häufung von 117 Linux-Kernel-CVEs mit CVSS ≥ 7 in 48 Stunden (28.–30.05.2026, OpenCVE-Filter vendor:linux AND cvss31>=7 AND created<=2d). Operativ substanziell ist CVE-2026-46227: „sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL“. Use-after-Free plus Type-Confusion im Pfad, der von list_for_each_entry_safe() über ep->asocs walkt — der Bug ist explizit als „reachable from CapEff=0“ beschrieben, der Type-Confusion-Pfad gibt einen controlled indirect call durch den Funktionspointer outqueue.sched->init_sid. Begleitfunde mit eigenständigem Hebel: CVE-2026-46154 (sched_ext cgroup UAF), CVE-2026-46209 und CVE-2026-46215 (drm/gem prime-swap race), CVE-2026-46197 (drm/amdkfd SVM nattr OOB), plus Cluster batman-adv und drm/amdgpu/vcn3/vcn4.

Wie schwer?

CVE-2026-46227 ist die einzige Klasse in der Welle mit expliziter unprivilegierter Pfad-Aussage und dokumentiertem Exploit-Hebel (controlled indirect call). Das ist die operativ wichtigste Klasse. Die übrigen Welle-Inhalte sind überwiegend lokale UAF-/Race-/OOB-Klassen mit eingeschränkter Exploitabilität. In einem Container-Stack ist /dev/dri-Zugriff nicht ungewöhnlich, die DRM-Klassen sind dort relevant.

Welche Kernel-Versionen sind betroffen?

Die einzelnen CVEs treffen verschiedene Upstream-Tags. Für CVE-2026-46227: alle SCTP-tragenden Kernels ab dem Commit, der list_for_each_entry_safe() in der SCTP_SENDALL-Schleife eingeführt hat, plus alle Backports davon in die LTS-Kernel (6.1, 6.6, 6.12 LTS-Linien). Distributions-Fixe wandern in die nächsten kernel-Z-Stream-Updates für RHEL/Rocky/Alma, Debian, Ubuntu, openSUSE.

Bin ich als Moselwal-Kunde betroffen?

Direkt betroffen sind alle Linux-Server, deren Kernel SCTP-Socket-Code geladen hat (Modul sctp oder built-in). SCTP wird in Telekommunikations-Kontexten (M3UA, Diameter, SIGTRAN), in einigen Cluster-Filesystem-Setups und in vielen Distributions als Modul automatisch geladen, sobald ein User einen SCTP-Socket erstellt — und das kann ein unprivilegierter Prozess. Wer SCTP nicht aktiv nutzt, sollte das Modul aus dem Kernel ausladen oder per blacklist blockieren — Mitigation Klasse Zero. Container-Stacks mit Workloads, die /dev/dri-Zugriff oder GPU-Compute brauchen, sind durch die drm/-Cluster relevant.

Sofort-Mitigation?

Drei Schritte. Erstens, SCTP-Nutzung prüfen (lsmod | grep sctp); wenn nicht aktiv genutzt, Modul blacklisten (echo "blacklist sctp" > /etc/modprobe.d/blacklist-sctp.conf und modprobe -r sctp). Zweitens, für aktive SCTP-Nutzer auf den Distributions-Kernel-Z-Stream-Update warten und einplanen, in der Zwischenzeit den unprivilegierten Zugriff auf AF_INET+SOCK_SEQPACKET+IPPROTO_SCTP-Socket-Erstellung über seccomp-Profile einschränken. Drittens, Standard-Kernel-Update-Disziplin in 7–14 Tagen.

Kritikalität?

Hero-Badge high. Aktive Ausnutzung Stand 30.05. nicht öffentlich dokumentiert. SCTP-LPE-Klassen haben historisch innerhalb von Wochen PoCs gesehen.

Was ist passiert

Eine OpenCVE-Abfrage mit vendor:linux AND cvss31>=7 AND created<=2d liefert am 30. Mai 2026 117 Treffer — deutlich mehr als der subjektive Eindruck eines typischen 48-Stunden-Fensters in den vergangenen Monaten. Die meisten dieser Treffer sind klassische Linux-Kernel-CNA-Disclosures (Linux-Kernel-CVE-Team unter der CNA von kernel.org), die in einem konzentrierten Drop-Zyklus veröffentlicht wurden. Inhaltlich verteilt sich die Welle über mehrere Subsystem-Cluster — drm/amdgpu/vcn (GPU-Treiber-Pfade), batman-adv (Mesh-Networking), drm/gem (Generic Memory Manager), media/iris (Qualcomm-Iris-Video-Codec im Staging), sched_ext (eBPF-basierter Scheduler), und einige Einzelfälle wie SCTP, HID-PlayStation, drm/amdkfd, xe.

Der substanzielle Befund in der Welle ist CVE-2026-46227 — „sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL“. Der Bug sitzt im SCTP_SENDALL-Pfad von sctp_sendmsg(), der über die Liste der SCTP-Assoziationen eines Endpoints (ep->asocs) mit list_for_each_entry_safe() walkt. Diese Iterations-Variante cached den nächsten List-Pointer (@tmp) bevor der Loop-Body ausgeführt wird. Das Problem: der Loop-Body ruft sctp_sendmsg_to_asoc() auf, das wiederum den Socket-Lock in sctp_wait_for_sndbuf() droppen kann. Während der Lock gedroppt ist, kann ein anderer Thread das in @tmp gecachte Association-Objekt per SCTP_SOCKOPT_PEELOFF an einen neuen Endpoint migrieren, und optional das neue Socket schließen — was die Association freigibt. Alternativ kann eine Network-ABORT die Association komplett freigeben.

Die Konsequenz beim Re-Lock: @asoc wird revalidiert, aber @tmp (der gecachte nächste Pointer) wird nicht revalidiert. Nach einem erfolgreichen Return advanced der Iterator auf das stale @tmp — entweder freed (Use-after-Free) oder, wenn die Association migriert wurde, auf einen struct list_head * einer anderen Endpoint-Liste (Type-Confusion). Die Beschreibung im Upstream-Commit ist explizit: „Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.“ Unprivilegiert ausnutzbar, mit exploitable indirect call.

Der Patch behebt die Lücke, indem @tmp nach jedem sctp_sendmsg_to_asoc()-Return aus @asoc neu abgeleitet wird.

Technische Einordnung

Strukturell gehört CVE-2026-46227 in eine Bug-Klasse, die im Linux-Kernel-Networking-Code immer wiederkehrt: List-Iteration mit Lock-Drop. Wenn eine Iteration über eine Datenstruktur den Lock zwischenzeitlich freigibt (für IO, Sleep, Wait), müssen alle gecachten Pointer revalidiert werden — nicht nur der aktuelle, sondern auch alle Hilfs-Pointer. Diese Klasse hat eine lange Historie im SCTP-Subsystem (Commit ba59fb027307 von 2019, „sctp: walk the list of asoc safely“, war eine ähnliche Korrektur).

Die spezifische Pointe bei CVE-2026-46227 ist der explizite Type-Confusion-Pfad. Use-after-Free auf einem zuvor freien Objekt ist eine Bug-Klasse, die in den letzten Jahren durch UAF-Defenses (SLUB-Hardening, randomisiertes Slab-Layout, KASAN in Production-Builds) deutlich schwerer ausnutzbar wurde. Type-Confusion ist eine andere Klasse — der Speicher ist nicht freigegeben, sondern wird als anderer Typ interpretiert, und wenn dieser andere Typ zufällig Funktionspointer trägt, ist der indirect-call-Pfad direkt da.

Methodisch wertvoll ist die explizite CapEff=0-Aussage. Linux-Kernel-CVEs geben in den letzten Jahren oft nicht klar an, welche Capabilities ein Angreifer braucht. CVE-2026-46227 bricht mit dieser Tendenz und sagt explizit: keine speziellen Capabilities nötig, der Bug-Pfad ist aus jedem unprivilegierten Prozess erreichbar. Das ist die Klasse von Klarheit, die Patch-Politik-Entscheidungen erleichtert.

Begleitfunde: CVE-2026-46154 (sched_ext cgroup UAF) ist relevant für Container-Stacks, die sched_ext nutzen. CVE-2026-46209/-46215 (drm/gem prime-swap race) sind lokal mit /dev/dri-Zugriff (Container mit Rendering-Workloads). CVE-2026-46197 (drm/amdkfd SVM nattr OOB) für AMD-ROCm-Workloads. Cluster batman-adv und drm/amdgpu/vcn3/vcn4 sind überwiegend nicht-Mittelstands-relevant.

Bedeutung für den Mittelstand

Für den deutschen Mittelstand sitzt der substanzielle Hebel der Welle bei zwei Klassen.

Erste Klasse: CVE-2026-46227 SCTP. Die Kernfrage lautet, ob auf Ihrem Linux-Server-Bestand das sctp-Kernel-Modul geladen ist und ob unprivilegierte Prozesse SCTP-Sockets öffnen können. In Standard-Distributionen ist sctp als Modul verfügbar und wird automatisch geladen, sobald ein Prozess einen SCTP-Socket erstellt — typisch bei Telco-Anwendungen (M3UA, Diameter, SIGTRAN), bei einigen Cluster-Filesystem-Setups, und in seltenen Fällen bei P2P- oder Latenz-optimierten Anwendungen. Wenn Ihre Plattform SCTP nicht aktiv nutzt — die typische Konfiguration für TYPO3-/Sylius-/Symfony-Webstacks —, ist die Mitigation einfach: sctp per modprobe-Blacklist deaktivieren, das Modul ausladen, fertig.

Zweite Klasse: CVE-2026-46154 sched_ext cgroup UAF. Relevant für Container-Stacks, die sched_ext aktiviert haben — was im Mai 2026 im DACH-Mittelstand noch eine Ausnahme ist, weil sched_ext in den meisten Distros noch nicht Default-Active ist.

Die übrigen Welle-Klassen (drm/-Cluster, batman-adv, HID, media/iris) sind im Mittelstand-Standard-Setting weniger akut — entweder weil die spezifische Hardware nicht im Server-Bestand ist, oder weil die spezifische Konfiguration (/dev/dri-Zugriff aus Containern) selten genutzt wird.

Compliance-seitig wirkt die Welle als Patch-Politik-Test. NIS-2 Art. 21 fordert für die betroffenen Sektoren konkrete Patch-Disziplin — eine Welle mit 117 CVEs in 48 Stunden ist genau die Klasse von Disclosure-Ereignis, an der man die eigene Patch-Politik prüft. Wer einen automatisierten SBOM-Workflow mit Kernel-Stand-Verfolgung hat, sieht die relevanten Treffer für seinen Bestand in einer Stunde. DSGVO Art. 32 ist über den indirekten Pfad betroffen — ein Linux-Server, der eine LPE-Lücke trägt und Personenbezugsdaten verarbeitet, ist eine technische-Maßnahmen-Lücke.

Bedeutung für die technische Entwicklung

Architektonisch zwingen die Welle und insbesondere CVE-2026-46227 zu drei Disziplinen.

Erstens, Kernel-Modul-Hygiene. Jeder Linux-Server lädt eine Menge Kernel-Module, die für die konkrete Workload nicht benötigt werden — Netzwerk-Protokolle (SCTP, DCCP, RDS, TIPC), Filesystem-Treiber (cramfs, freevxfs, jffs2, hfs), Geräte-Treiber für nicht-vorhandene Hardware. Ein guter Hardening-Schritt für jeden Server ist eine modprobe-Blacklist für nicht-genutzte Module — das CIS-Benchmark-Pattern, das in BSI-Grundschutz, DISA-STIG und vielen Mittelstands-Hardening-Guides beschrieben ist. CVE-2026-46227 ist genau die Klasse, die diese Disziplin lohnenswert macht.

Zweitens, Container-Capability-Audit. Welche Capabilities haben Ihre Container? Welche brauchen sie wirklich? /dev/dri-Zugriff für Rendering-Workloads ist sinnvoll, sollte aber nicht in jedem Container default-mounted sein. SCTP-Socket-Erstellung lässt sich per seccomp blockieren — wer einen restriktiven seccomp-Profil hat (Default für Kubernetes-PodSecurityStandards restricted), blockiert die ganze Klasse von SCTP-Bugs schon auf dem Container-Boundary.

Drittens, Kernel-Patch-Pipeline-Tempo. Die Welle zeigt, dass Linux-Kernel-CVE-Disclosure in 2026 in einer höheren Frequenz läuft. Wer im Mittelstand auf einen monatlichen Kernel-Patch-Zyklus optimiert ist, hat in 2026 zu langsam — wöchentliche Updates für Container-Images, mindestens 14-tägige Updates für Bare-Metal-Hosts sind die neue Mindestkadenz.

Konkrete Handlungsempfehlung

In dieser Reihenfolge. Erstens, SCTP-Inventur heute: auf jedem Linux-Host prüfen, ob sctp als Modul geladen ist (lsmod | grep sctp) und ob die Workload SCTP aktiv nutzt. Wenn SCTP nicht genutzt wird: per modprobe-Blacklist deaktivieren (echo "blacklist sctp" > /etc/modprobe.d/blacklist-sctp.conf) und das Modul ausladen (modprobe -r sctp). Damit ist CVE-2026-46227 für diesen Host strukturell mitigiert, unabhängig vom Kernel-Patch-Stand. Zweitens, für aktive SCTP-Nutzer: auf den Distributions-Kernel-Z-Stream-Update mit dem Upstream-Backport für CVE-2026-46227 warten; in der Zwischenzeit prüfen, ob die SCTP-Socket-Erstellung aus unprivilegierten Prozessen unbedingt erlaubt sein muss (ggf. per seccomp-Profil einschränken). Drittens, Container-Stack-Audit für sched_ext: prüfen, ob in Ihrem Container-Cluster sched_ext aktiviert ist; wenn ja, CVE-2026-46154 in die Patch-Liste setzen. Viertens, /dev/dri-Audit: in der Container-Workload-Definition prüfen, welche Container /dev/dri-Zugriff haben; bewerten, ob das wirklich notwendig ist. Fünftens, Kernel-Update-Pipeline einrichten, falls noch nicht vorhanden: für Container-Base-Images eine wöchentliche Re-Build-Kadenz, für Bare-Metal-Hosts eine 14-tägige Patch-Pipeline mit automatisierter Reboot-Planung. Sechstens, SBOM-Spur für Kernel-Stand: in den SBOM-Workflow den Kernel-Paket-Stand pro Host und pro Container-Image aufnehmen.

Wenn diese Schritte aus eigener Kraft nicht laufen, sprechen Sie mit uns: Moselwal liefert Plattformen, in denen Kernel-Modul-Hygiene, Container-Capability-Audit und Patch-Pipeline-Tempo als laufender Prozess sitzen.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• OpenCVE — CVE-2026-46227: SCTP SCTP_SENDALL UAF + Type-Confusion (30.05.2026)
• OpenCVE — Linux Kernel CVE-Welle (Abfrage 30.05.2026, 117 Treffer)
• Red Hat Customer Portal — CVE-2026-46227 (Stand 30.05.2026)
• xairy/linux-kernel-exploitation — Sammlung Linux-Kernel-Security-Exploitation-Material
• Linux Kernel Documentation — SCTP (Stand 30.05.2026)