Kurzfassung

Im Linux-Kernel sind mehrere zusammenhängend bekannt gewordene Schwachstellen behoben worden, darunter CVE-2026-89775, CVE-2026-89778, CVE-2026-89779, CVE-2026-89783, CVE-2026-89786, CVE-2026-89788 sowie neu CVE-2026-89846, CVE-2026-89847 und CVE-2026-89857. Besonders relevant sind die netzwerkseitig erreichbaren Fehler mit CVSS 9.8, kritisch, etwa in ksmbd, dem IPv6-XFRM-Pfad und nun auch im qla2xxx-Treiber für Fibre-Channel-/NVMe-FC-Umgebungen; hinzu kommt ein weiterer kritischer qla2xxx-Fehler mit CVSS 9.1. Für Unternehmen zählt jetzt vor allem, ob betroffene Kernel-Funktionen wie SMB-Server im Kernel, IPsec/XFRM, das Mounten fremder Images, arm64-KVM oder QLogic-basierte Storage-/SAN-Anbindungen im Einsatz sind.

Was ist passiert?

Die NVD führt derzeit mehrere Linux-Kernel-Schwachstellen, die unterschiedliche Teilbereiche des Kernels betreffen, aber ein gemeinsames Muster zeigen: fehlerhafte Grenzprüfungen, ungültige Zustände oder Rennen bei der Speicherverwaltung führen zu Out-of-Bounds-Lese- oder Schreibzugriffen beziehungsweise Use-after-free-Situationen.

Betroffen sind sowohl Virtualisierung als auch Netzwerkpfade, Dateisystemcode und nun zusätzlich Storage-nahe Treiberpfade. CVE-2026-89775 betrifft KVM auf arm64, konkret die Behandlung eines Sonderzustands bei der Auswertung von TLB-Invalidierungen. CVE-2026-89783 sitzt im IPv6-XFRM-Pfad. CVE-2026-89788 betrifft ksmbd, also den SMB-Server direkt im Kernel. Hinzu kommen Dateisystemfehler in isofs mit zisofs-Kompression unter CVE-2026-89778, in ntfs3 unter CVE-2026-89779 und in ext4 unter CVE-2026-89786. Neu hinzugekommen sind mit CVE-2026-89846, CVE-2026-89847 und CVE-2026-89857 drei kritische Einträge im qla2xxx-Treiber aus dem SCSI-Umfeld.

Die Bandbreite reicht damit von eher spezialisierten Konfigurationen bis zu Komponenten, die in Linux-Umgebungen im Rechenzentrum durchaus realistisch genutzt werden. Nicht jede dieser Lücken ist für jede Installation gleich brisant. Ein öffentlich erreichbarer ksmbd-Dienst oder ein exponierter IPsec-Stack wiegt klar schwerer als ein nur lokal relevanter Fehler in arm64-KVM. Für SAN- und NVMe-over-Fibre-Channel-Umgebungen rücken die neuen qla2xxx-Meldungen allerdings ebenfalls weit nach oben, weil sie laut NVD netzwerkseitig erreichbar und teils ohne Authentifizierung ausnutzbar sind.

Technische Details

Die höchste ausgewiesene technische Schwere liegt bei CVSS 9.8. Der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H und bedeutet: Ein Angriff ist über das Netzwerk möglich, mit geringer Komplexität, ohne Berechtigungen und ohne Nutzerinteraktion; Vertraulichkeit, Integrität und Verfügbarkeit können jeweils schwer beeinträchtigt werden. Dieser Wert beschreibt die technische Schwere, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

CVE-2026-89778 beschreibt einen Out-of-Bounds-Zugriff in isofs beim Lesen eines präparierten ISO9660-Abbilds mit komprimierten zisofs-Daten. Ein leerer Block in einem manipulierten „ZF“-Rock-Ridge-Eintrag kann dazu führen, dass beim normalen Lesen einer Datei auf ein Seitenarray außerhalb des gültigen Bereichs zugegriffen wird.

CVE-2026-89779 betrifft ntfs3. Dort wird bei Extended Attributes die Größe eines Datensatzes unzureichend gegen enthaltene Namens- und Wertfelder geprüft. Ein manipuliertes Abbild kann dazu führen, dass der Kernel beim Auslesen von Attributen über das allokierte Objekt hinaus liest und dadurch Speicherinhalte an den Nutzerraum preisgibt.

CVE-2026-89783 liegt im IPv6-XFRM-Code. Eine fehlerhafte Tiefenprüfung führt bei voller secpath-Struktur zu einem Schreibzugriff außerhalb des vorgesehenen Arrays. Der Fehler entsteht durch eine Off-by-one-Prüfung und kann im Zusammenspiel mit erneut in den IPv6-Eingabepfad eingespeisten Paketen auftreten.

CVE-2026-89786 sitzt in ext4 bei Inline-Verzeichnissen. Dort kann der Kernel beim Verzeichnislesen einen Dirent-Header außerhalb des tatsächlichen Puffers dereferenzieren. Praktisch ist das ein Out-of-Bounds-Read, ausgelöst durch unzureichende Längenprüfung zwischen logischem Positionsraum und real allokiertem Speicher.

CVE-2026-89788 ist aus Betriebssicht besonders heikel, weil ksmbd netzwerkseitig exponiert sein kann. Der Fehler ist ein Use-after-free in smb2_tree_connect(): Eine neue Tree-Connection wird veröffentlicht, bevor ihre Initialisierung vollständig abgeschlossen ist. Meldet sich eine Sitzung gleichzeitig ab, kann das Objekt freigegeben werden, während der Verbindungsaufbau es noch verwendet.

CVE-2026-89775 weicht davon ab: Die Lücke betrifft KVM auf arm64 und ist laut NVD lokal statt netzwerkseitig angreifbar. Ein negativer S1-Walk-Level für deaktivierte MMU-Zustände wird fehlerhaft behandelt, wodurch die Größe einer TLB-Invalidierung falsch berechnet werden kann. Die NVD nennt hier einen CVSS-Basiswert von 9.3.

Neu hinzugekommen ist CVE-2026-89846 im qla2xxx-Treiber. Dort wird im FWI2-Statuspfad ein vom Zielsystem gemeldeter rsp_info_len-Wert aus der FCP-Antwort verwendet, um einen Zeiger auf Sense-Daten vorzuverschieben und die verbleibende Länge zu verkleinern. Wird dieser Wert nicht auf die tatsächliche IOCB-Datenbereichsgröße begrenzt, kann die Längenrechnung unterlaufen und ein Out-of-Bounds-Read entstehen. In der Folge kann beim Kopieren in den Sense-Puffer Speicher aus benachbarten Ring- oder Heap-Bereichen offengelegt werden. Die NVD bewertet den Fehler mit CVSS 9.1.

CVE-2026-89847 betrifft ebenfalls qla2xxx und beschreibt eine Double-Completion-Situation bei einem Timeout asynchroner IOCBs. Wenn ein Timeout-Pfad und die reguläre Antwortverarbeitung dasselbe SRB-Objekt konkurrierend abschließen, kann sp->done() doppelt aufgerufen werden. Laut Fehlerbeschreibung kann das in eine Use-after-free-Situation auf einem bereits freigegebenen Stack-Frame münden. Die NVD bewertet den Eintrag mit CVSS 9.8.

CVE-2026-89857 sitzt erneut in qla2xxx, diesmal im Umgang mit NVMe-LS-Reject-IOCBs. Dort werden Request-Ring-Operationen in bestimmten Aufruferpfaden ohne den erwarteten qpair-/hardware_lock ausgeführt. Wenn diese Pfade parallel zu normaler I/O-Einreichung auf demselben Ring laufen, kann der Producer-Zustand des Rings beschädigt werden, was zu duplizierten oder verlorenen Kommandos führen kann. Auch dieser Eintrag wird von der NVD mit CVSS 9.8 geführt.

Wer ist betroffen?

Betroffen sind Linux-Systeme mit einem Kernelstand, in dem die fehlerhaften Codepfade noch enthalten sind. Die NVD nennt in diesen Einträgen keine einfache, distributionsbezogene Liste konkreter Kernel-Versionen. Für Administratoren im DACH-Raum ist deshalb entscheidend, welche Kernel-Funktionen tatsächlich aktiviert oder genutzt werden.

Hohes praktisches Risiko besteht vor allem für Systeme mit aktivem ksmbd, also dem SMB-Server im Kernel, insbesondere wenn dieser aus untrusted Netzen erreichbar ist. Ebenfalls relevant sind Hosts mit IPv6- und IPsec-/XFRM-Nutzung, etwa Gateways, VPN-Endpunkte oder spezialisierte Netzwerkrollen.

Dateisystembezogene Lücken wie CVE-2026-89778 in isofs, CVE-2026-89779 in ntfs3 und CVE-2026-89786 in ext4 sind vor allem dort kritisch, wo fremde oder von Dritten gelieferte Images, Datenträger oder Container-Inhalte automatisiert eingehängt, gescannt oder verarbeitet werden. Das betrifft Build-Pipelines, Malware-Analyse, Forensik, Backup-Prüfstrecken und Virtualisierungsumgebungen eher als klassische Office-Clients.

CVE-2026-89775 ist vor allem für Betreiber von arm64-Systemen mit KVM relevant. Wer kein arm64-KVM einsetzt, kann diese Teilmeldung deutlich niedriger priorisieren als die netzwerkseitigen Kernel-Fehler.

Neu betroffen sind zudem Umgebungen mit qla2xxx-Treibern, also insbesondere Systeme mit QLogic-basierten Fibre-Channel- oder verwandten Storage-Anbindungen im Rechenzentrum. Praktisch relevant ist das vor allem für SAN-Hosts, Virtualisierungsknoten, Storage-Gateways und NVMe-over-Fibre-Channel-Setups. Wer diese Hardware und Treiber nicht nutzt, kann CVE-2026-89846, CVE-2026-89847 und CVE-2026-89857 in der Priorisierung meist nachrangig behandeln; wer sie im produktiven Fabric einsetzt, sollte die neuen Meldungen dagegen nicht als exotisch abtun.

Empfohlene Maßnahmen

  1. Kernel-Updates priorisieren: Prüfen Sie umgehend, ob Ihre Distribution bereits Sicherheitsupdates für den Linux-Kernel bereitstellt. In Unternehmensumgebungen sollten zuerst Internet-exponierte oder mandantenfähige Systeme aktualisiert werden.
  2. ksmbd sofort bewerten: Wenn ksmbd aktiv ist, priorisieren Sie CVE-2026-89788 ganz oben. Ist ein kurzfristiges Update nicht möglich, schalten Sie den Dienst ab oder begrenzen Sie den Zugriff strikt auf vertrauenswürdige Netze.
  3. XFRM/IPsec und IPv6 prüfen: Bei Gateways, VPN-Systemen und Appliances mit XFRM-Nutzung sollte CVE-2026-89783 mit hoher Dringlichkeit behandelt werden. Reduzieren Sie bis zum Patch gegebenenfalls unnötige Erreichbarkeit und filtern Sie Verkehr so eng wie möglich.
  4. Umgang mit fremden Images einschränken: Für CVE-2026-89778 und CVE-2026-89779 gilt: Mounten oder verarbeiten Sie ISO- und NTFS-Abbilder aus unsicheren Quellen nur in isolierten Umgebungen. Automatisierte Prüf- oder Importprozesse verdienen hier besondere Aufmerksamkeit.
  5. arm64-KVM gesondert betrachten: Betreiber von ARM-Servern mit KVM sollten CVE-2026-89775 in die Wartungsplanung aufnehmen, auch wenn die praktische Angriffsfläche kleiner ist als bei den netzwerkseitigen Fehlern.
  6. qla2xxx/SAN-Pfade inventarisieren und patchen: Prüfen Sie, ob betroffene QLogic-basierte Fibre-Channel- oder NVMe-FC-Treiber im Einsatz sind. Für SAN-Hosts und Storage-nahe Systeme sollten CVE-2026-89846, CVE-2026-89847 und CVE-2026-89857 zügig in die Patch-Priorisierung aufgenommen werden, insbesondere in gemeinsam genutzten oder exponierten Fabric-Umgebungen.
  7. Kernel-Features inventarisieren: Viele Organisationen wissen nicht belastbar, ob ksmbd, ntfs3, qla2xxx oder bestimmte XFRM-Pfade überhaupt genutzt werden. Diese Transparenz ist hier wichtiger als pauschale Alarmierung aller Linux-Systeme.

Ein Hersteller-Advisory mit Patch-Referenzen wurde nicht mitgeteilt. In der Praxis sollten Sie daher die Sicherheitskanäle Ihrer Distribution verfolgen, etwa für Red Hat, SUSE, Ubuntu, Debian oder Oracle Linux, je nach eingesetzter Plattform.

Einschätzung von CyberSecurity-News.de

Die Sammellage wirkt auf den ersten Blick dramatisch, weil mehrere Kernel-Fehler gleichzeitig mit hohen Bewertungen auftauchen. Für die operative Priorisierung genügt dieser Blick aber nicht. Zwischen einem lokal ausnutzbaren arm64-KVM-Problem und einem potenziell über das Netzwerk erreichbaren Use-after-free in ksmbd liegt im Alltag ein erheblicher Unterschied.

Auffällig ist außerdem, dass die NVD-Einträge sehr technische Fix-Beschreibungen enthalten, aber ohne distributionsnahe Einordnung. Das ist für Kernel-Themen nicht ungewöhnlich, hilft Admins im Betrieb jedoch nur begrenzt. Entscheidend ist nicht die CVE-Liste an sich, sondern ob die betroffenen Subsysteme auf den eigenen Systemen aktiv sind.

Ein Teil der hohen Bewertungen dürfte aus generischen Angriffsannahmen resultieren, insbesondere bei Dateisystemcode, der in vielen realen Umgebungen nur über zusätzliche Verarbeitungsschritte erreichbar ist. Das relativiert die Gefahr nicht, aber es verschiebt die Priorität: erst öffentliche Dienste und Netzwerkpfade, dann Spezialkonfigurationen und lokale Angriffsflächen.

Die neuen qla2xxx-Einträge ändern diese Gewichtung nicht grundsätzlich, erweitern sie aber um ein wichtiges Rechenzentrums-Szenario. Auf klassischen Linux-Servern ohne entsprechende HBAs bleiben ksmbd und XFRM die praktisch naheliegenderen Sofortthemen. In SAN- oder NVMe-FC-Umgebungen dagegen sind qla2xxx-Probleme keineswegs theoretisch, sondern können unmittelbar produktionsrelevante Storage-Pfade betreffen.

Fazit

Unternehmen sollten diese Linux-Kernel-Lücken nicht pauschal, sondern nach tatsächlicher Exposition behandeln. Höchste Priorität haben ksmbd und IPv6/XFRM auf erreichbaren Systemen, dicht gefolgt von qla2xxx-basierten SAN- und NVMe-FC-Umgebungen sowie danach Workloads, die fremde ISO- oder NTFS-Abbilder verarbeiten.

Wer Linux im Serverbetrieb nutzt, sollte jetzt Kernel-Stände gegen die eigenen Distributionsupdates abgleichen und unnötige Kernel-Dienste vorübergehend deaktivieren. Ohne belastbare Inventarisierung der genutzten Kernel-Funktionen ist eine saubere Risikobewertung hier kaum möglich.

Quellenangabe