HochCVE-2026-98991

    Linux Kernel: Use-After-Free (CVE-2026-98991)

    Veröffentlicht Zuletzt geändert Quellen: CVE.org, BSI

    Was ist betroffen, was ist zu tun

    Aktualisieren Sie Linux Kernel auf Version 6.18.57, Linux Kernel auf Version 7.2.11, Linux Kernel auf Version 7.3.

    Betroffen
    • Linux Kernel lt 6.15..6.18.57
    • Linux Kernel lt 6.19..7.2.11
    Behoben in
    • Linux Kernel 6.18.57
    • Linux Kernel 7.2.11
    • Linux Kernel 7.3

    Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

    Metriken

    7,8

    Priorität

    XIEM Effective CVSS: höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.

    Quelle: Hersteller (CNA), CVSS v3

    7,8

    CVSS v3

    Schweregrad Hoch auf der Skala von 0 bis 10.

    Quelle: CVE.org, BSI

    0,2 %

    EPSS-Score

    Niedrig – Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.

    Quelle: FIRST EPSS, Perzentil 4,8

    Alle Metriken anzeigen
    Schweregrad
    Hoch
    Priorität (0–325)

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    69.18 Methodik
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    kein öffentlicher PoC bekannt
    XIEM Effective CVSS

    XIEM® ist das gestufte Managed-Security-Betriebsmodell von NEOSEC und eine eingetragene Marke der NEOSEC GmbH. Es erweitert klassisches SIEM — die zentrale Sammlung, Normalisierung und Korrelation sicherheitsrelevanter Ereignisse — um Endpunkt-Forensik, Netzwerk-Sichtbarkeit und Täuschungstechnik und führt diese zu drei aufeinander aufbauenden Stufen zusammen: Sentry, Orchestrate und Command.

    Im Glossar lesen
    7,8 Methodik
    CVSS v3

    CVSS ist der weltweit verbreitete, offene Standard zur Bewertung der technischen Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Er beschreibt, wie leicht eine Lücke ausnutzbar ist und welchen Schaden sie anrichten kann — nicht jedoch, wie wahrscheinlich ihre tatsächliche Ausnutzung ist. CVSS und das ergänzende EPSS beantworten bewusst unterschiedliche Fragen.

    Im Glossar lesen
    7,8
    EPSS-Score

    Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.

    Im Glossar lesen
    0,2 %
    Niedrig – Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
    EPSS-Perzentil

    Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.

    Im Glossar lesen
    4,8
    Niedrig – CVE gehört zu den unteren 10 % der heute bewerteten CVEs.
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    —
    Veröffentlicht

    Erkennungsregeln

    Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Hohe technische Schwere: Bewerten und beheben Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 und dokumentieren Sie die Entscheidung.
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Im Linux-Kernel wurde folgende Schwachstelle behoben:

    Namespace: Einbinden nur einmal für Einbindenachrichten

    mnt_notify_add() fügt eine Einbindung in die notify_list ein. Es überprüft nicht, ob die Einbindung bereits in der Liste vorhanden ist. Das ist in Ordnung, solange jede Einbindung höchstens einmal pro namespace_sem-Haltung eingereiht wird. Das ist jedoch nicht der Fall.

    propagate_umount() verschiebt eine überlebende Über-Einbindung von einer Stapel von Einbindungen, die verschwinden, und reiht sie als verschoben ein. shrink_submounts() und mark_mounts_for_expiry() rufen umount_tree() für mehrere Einbindungen unter einer einzigen namespace_sem-Haltung auf. Daher kann das zweite umount_tree() genau die Einbindung, die das erste neu verknüpft hat, erneut neu verknüpfen und sie zweimal einreihen.

    Der zweite list_add_tail() entfernt die zwischen eingereihten Einbindungen aus der Liste, während der Kopf noch auf das letzte davon zeigt. notify_mnt_list() besucht dann nur diese eine Einbindung und die anderen werden nach der Gnadenfrist freigegeben, während notify_list noch auf sie zeigt. Jede spätere Einbindungsoperation auf dem Host durchläuft freigegebene Speicher:

      BUG: KASAN: slab-use-after-free in __list_add_valid_or_report
  Lesen der Größe 8 an der Adresse ffff8881003d57e0 durch die Aufgabe notify_dq/162
   __list_add_valid_or_report+0x15c/0x1a0
   mnt_add_to_ns+0x322/0x890
   attach_recursive_mnt.isra.0+0xf2a/0x1a00
   path_mount+0x139c/0x1d40

    Dafür wird eine Einbindung mit MNT_SHRINKABLE benötigt, um zu binden. Das ist, was finish_automount() erstellt (Untereinbindungen von NFS, AFS und CIFS und die Einbindung von tracefs unter debugfs). Bind-Einbindungen erben die Flagge. Ein Einbindungsnamespace mit einem FAN_MARK_MNTNS-Markierungszeichen macht den Rest und die Wurzel in einem Benutzer-namespace kann beides haben.

    Initialisiere to_notify in alloc_vfsmnt() und lasse eine Einbindung unberührt, die bereits eingereiht ist. mnt_notify() betrachtet den Zustand der Einbindung, wenn die Liste entleert wird, daher reicht ein einzelner Eintrag pro Einbindung aus. Das Verschiebeereignis für eine Einbindung, die unter demselben Haltung entfernt wird, geht verloren. Das ist in Ordnung. Das Trennen ist das, was zählt.

    Quelle: cvelistv5, NVD (NIST), BSI CSAF, BSI WID Portal

    Betroffene Produkte

    Betroffen sind die folgenden Versionen. Ältere Stände derselben Reihe sind ebenfalls verwundbar, sofern nicht anders angegeben.

    Betroffene Produkte
    Betroffene VersionenBehoben in
    LinuxLinux
    • 6.19 – < 7.2.11
    • —
    • 6.15 – < 6.18.57
    • 7.2.11
    • 7.3
    • 6.18.57

    Hersteller und Produkte

    Quellen & Referenzen

    Änderungen an der CVE

    Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).

    1. Eintrag geändertLinux

      CVSS V3.1: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

      Einzeländerung im Original anzeigen
      Einzeländerungen dieses Ereignisses im Original der NVD
      ArtAktionVorherNachher
      CVSSergänzt
      —
      AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

      Kennung der Quelle: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    2. Neu erfasstLinux

      Beschreibung erfasst oder geändert

      5 Einzeländerungen im Original anzeigen
      Einzeländerungen dieses Ereignisses im Original der NVD
      ArtAktionVorherNachher
      Beschreibungergänzt
      —
      In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace with a FAN_MARK_MNTNS mark does the rest and root in a user namespace can have both. Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is queued already. mnt_notify() looks at the state the mount has when the list is drained so a single entry per mount is enough. The move event for a mount that is unmounted under the same hold is lost. That's fine. The detach is what matters.
      Betroffene Versionen (Herausgeber)ergänzt
      —
      New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98991.json">CVE-2026-98991</a>
      Referenzergänzt
      —
      https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab
      Referenzergänzt
      —
      https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190
      Referenzergänzt
      —
      https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762

      Kennung der Quelle: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Badge einbetten

    Zeigen Sie Schweregrad und KEV-Status dieser Schwachstelle auf Ihrer Seite – mit Link hierher. Das Bild wird stündlich aktualisiert.

    Badge-Vorschau für CVE-2026-98991
    <a href="https://intel.neosec.eu/cve/CVE-2026-98991"><img src="https://intel.neosec.eu/badge/cve/CVE-2026-98991.svg" alt="CVE-2026-98991 – NEOSEC Intel" height="20"></a>