HochCVE-2026-97595

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

    Veröffentlicht Zuletzt geändert Quellen: Debian, CVE.org, Msrc Update Guide, BSI

    Was ist betroffen, was ist zu tun

    Aktualisieren Sie Linux Kernel auf Version 6.6.158, Linux Kernel auf Version 6.12.111, Linux Kernel auf Version 6.18.53.

    Betroffen
    • Linux Kernel lt 6.3..6.6.158
    • Linux Kernel lt 6.7..6.12.111
    • Linux Kernel lt 6.13..6.18.53
    • Linux Kernel lt 6.19..7.2.7
    Behoben in
    • Linux Kernel 6.6.158
    • Linux Kernel 6.12.111
    • Linux Kernel 6.18.53
    • Linux Kernel 7.2.7
    • Linux Kernel 7.3

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

    Metriken

    7,5

    Priorität

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

    Quelle: Hersteller (CNA), CVSS v3

    7,5

    CVSS v3

    Schweregrad Hoch auf der Skala von 0 bis 10.

    Quelle: Debian, CVE.org, Msrc Update Guide, BSI

    0,3 %

    EPSS-Score

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

    Quelle: FIRST EPSS, Perzentil 19,7

    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
    70.59 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,5 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,5
    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,3 %
    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
    19,7
    Erhöht – CVE ist relevanter als mindestens 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:

    mac802154: Behebung der Use-After-Free von sdata über eingehende RX-Frames

    Der RX-Softirq-Produzent ieee802154_subif_frame() fügt empfangene Beacon- und MAC-Befehlsframes in die lokalen Listen local->rx_beacon_list / rx_mac_cmd_list ein und plant einen Prozesskontext-Arbeiter, der einen rohen mac_pkt->sdata (und skb->dev == sdata->dev) speichert, ohne dabei eine Referenz oder Sperre zu verwenden:

    • Die Listen sind nicht gesperrt: Der Softirq-Produzent list_add_tail() während der mac_wq-Arbeiter list_del() verwendet, sodass benachbarte Schnittstellen auf demselben phy die Liste beschädigen;

    • Die Arbeiter entreferenzieren die Schnittstelle, nachdem sie möglicherweise freigegeben wurde. mac802154_rx_mac_cmd_worker() greift direkt auf mac_pkt->sdata zu, und mac802154_rx_beacon_worker() -> mac802154_process_beacon() entreferenziert skb->dev (== sdata->dev). Das Entfernen einer Schnittstelle gibt ihr sdata (netdev_priv) frei, während ein eingehängter Frame immer noch darauf zeigt, sodass ein späterer Arbeiterlauf eine Use-After-Free darstellt.

    Reproduziert unter KASAN durch Fluten einer Opferschnittstelle mit MAC-Befehlsframes und deren Entfernung (der Beacon-Pfad ist über skb->dev derselbe):

    BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Lesen der Größe 4 an der Adresse ffff888002f9ea18 durch die Aufgabe kworker/u8:1/31 Arbeitswarteschlange: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Aufrufverfolgung: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0

    Beide Listen zusammen beheben:

    • Fügen Sie local->rx_lock hinzu und nehmen Sie es um jeden Listenzugriff: der Softirq-Produzent (einfache spin_lock, Softirq-Kontext) und die Arbeiter und den Flush (spin_lock_bh, Prozesskontext);

    • Fixieren Sie die Schnittstelle für die Lebensdauer eines eingehängten Frames mit netdev_hold()/netdev_put(), sodass der Arbeiter sdata / skb->dev sicher entreferenzieren kann, auch wenn die Schnittstelle entfernt wird;

    • Entfernen Sie unter der Sperre an der Spitze und leeren Sie die gesamte Liste in den Arbeitern (sie verarbeiteten zuvor pro Lauf einen Frame und verließen sich auf eine spätere Einfügung, um den Rest zu entleeren);

    • Löschen Sie Frames, die noch nicht gestartet wurden, einer Schnittstelle, bevor sie abgemeldet wird, aus ieee802154_if_remove() (nach der RCU-Grace-Periode) und aus der Schleife ieee802154_remove_interfaces() -- der letztere ist der gesamte-phy-Aufräumweg, der nicht über ieee802154_if_remove() geht.

    Ein in der Luft befindlicher Arbeiter, der bereits einen Frame entdeckt hat, behält seine eigene netdev-Referenz; unregister_netdevice() wartet dann darauf in netdev_run_todo(), das bei rtnl_unlock() (rtnl freigegeben) und nachdem die Schnittstelle geschlossen wurde, ausgeführt wird, sodass es nicht rtnl festlegt. Ein Arbeiter, der in einer Assoziations-Übertragung blockiert ist, verzögert nur die Abmeldung dieser einen Schnittstelle (die übliche "Warten auf %s, um frei zu werden"), hält jedoch nicht rtnl. netdev_hold() wird aus diesem Grund anstelle einer cancel_work_sync() unter rtnl verwendet, die auf den ungebundenen MLME-Übertragungswartezustand des Arbeiters über ieee802154_sync_queue() blockieren würde.

    Der mac-Befehlsarbeiter überspringt zusätzlich die Verarbeitung für eine gestoppte Schnittstelle (ieee802154_sdata_running()), um eine unnötige Assoziationsantwort während des Aufräumens zu vermeiden.

    Quelle: Debian Security Advisories, cvelistv5, Microsoft Security Update Guide, NVD (NIST), BSI WID Portal, BSI CSAF

    Betroffene Produkte

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

    Betroffene Produkte
    HerstellerProduktBetroffene VersionenBehoben in
    LinuxLinux
    • 6.3 – < 6.6.158
    • 6.13 – < 6.18.53
    • —
    • 6.19 – < 7.2.7
    • 6.7 – < 6.12.111
    • 6.6.158
    • 6.18.53
    • 7.3
    • 7.2.7
    • 6.12.111

    Betroffene Betriebssysteme

    Betroffene Betriebssysteme
    FamilieHerstellerProduktVersion
    Linuxdebianlinuxtrixie

    Quellen & Referenzen

    Re-Analyse & Statuswechsel

    Chronologie der NVD-Audit-Events für diese CVE – Reanalyses, CVSS-Updates, CPE-Diffs.

    1. CVE Modified416baaa9-dc9f-4396-8d5f-8c081fb06d67

      • Affected: nachher Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97595.json">CVE-2026-97595</a>

    2. CVE Modified416baaa9-dc9f-4396-8d5f-8c081fb06d67

      • Affected: nachher Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97595.json">CVE-2026-97595</a>
      • Reference: nachher https://git.kernel.org/stable/c/4826fd8373f684f9952536333ad45b26acd3455d

    3. CVE Modified416baaa9-dc9f-4396-8d5f-8c081fb06d67

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

    4. New CVE Received416baaa9-dc9f-4396-8d5f-8c081fb06d67

      • Description: nachher In the Linux kernel, the following vulnerability has been resolved: mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual "waiting for %s to become free"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown.
      • Affected: nachher New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97595.json">CVE-2026-97595</a>
      • Reference: nachher https://git.kernel.org/stable/c/07f0214018d7241e3610c1be984c8abfce16c099
      • Reference: nachher https://git.kernel.org/stable/c/2f37fba846c9fdff5fc15b6d93656057ccd13031
    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-97595
    <a href="https://intel.neosec.eu/cve/CVE-2026-97595"><img src="https://intel.neosec.eu/badge/cve/CVE-2026-97595.svg" alt="CVE-2026-97595 – NEOSEC Intel" height="20"></a>