Linux Kernel: Null-Pointer-Dereferenzierung (CVE-2026-80819)
Veröffentlicht Zuletzt geändert Quellen: SUSE, HKCERT, Ubuntu, Debian LTS, CVE.org, EUVD, Msrc Update Guide, BSI
Was ist betroffen, was ist zu tun
Aktualisieren Sie Linux Kernel auf Version 5.10.267, Linux Kernel auf Version 5.15.218, Linux Kernel auf Version 6.1.185.
- Betroffen
- Linux Kernel
lt 2.6.30..5.10.267 - Linux Kernel
lt 5.11..5.15.218 - Linux Kernel
lt 5.16..6.1.185 - Linux Kernel
lt 6.2..6.6.154 - Linux Kernel
lt 6.7..6.12.106 - Linux Kernel
lt 6.13..6.18.47 - Linux Kernel
lt 6.19..7.1.11 - Linux Kernel
lt 7.2..7.2.1
- Linux Kernel
- Behoben in
- Linux Kernel
5.10.267 - Linux Kernel
5.15.218 - Linux Kernel
6.1.185 - Linux Kernel
6.6.154 - Linux Kernel
6.12.106 - Linux Kernel
6.18.47 - Linux Kernel
7.1.11 - Linux Kernel
7.2.1 - Linux Kernel
7.3
- Linux Kernel
Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen
Metriken
6,5
XIEM Effective CVSS
Höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.
Quelle: Hersteller (CNA), CVSS v3
6,5
CVSS v3
Schweregrad Mittel auf der Skala von 0 bis 10.
Quelle: SUSE, HKCERT, Ubuntu, Debian LTS, CVE.org, EUVD, Msrc Update Guide, BSI
0,2 %
EPSS-Score
Niedrig – Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Quelle: FIRST EPSS, Perzentil 9,3
Alle Metriken anzeigen
- Schweregrad
- Mittel
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- 57.26 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- 6,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- 6,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,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- 9,3
- 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- Behandeln Sie die Schwachstelle im regulären Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2.
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:
Bluetooth: RFCOMM: nehme rfcomm_mutex für den verzögerten Setup-Akzept an
Die Funktion rfcomm_sock_recvmsg() vervollständigt ein verzögertes Setup, indem sie rfcomm_dlc_accept() aufruft, ohne einen RFCOMM-Schutz zu halten:
if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
rfcomm_dlc_accept(d);
return 0;
}
und rfcomm_dlc_accept() dereferenziert die Sitzung auf der ersten Zeile:
struct sock *sk = d->session->sock->sk;
Jeder andere Pfad, der d->session berührt, läuft unter rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn() und die RFCOMM-Schleife durch rfcomm_process_sessions(). rfcomm_connect_ind() ist sogar dokumentiert als "unter rfcomm_lock() aufgerufen". Dieser Aufrufspunkt ist der einzige, der ihn überspringt.
Der Bit RFCOMM_DEFER_SETUP sieht so aus, als würde er den Akzept gegen das Abbrechen serialisieren, da __rfcomm_dlc_close() frühzeitig zurückkehrt, wenn es die Prüfung und Löschung gewinnt. Aber rfcomm_recv_disc() zwingt den Zustand zuerst:
d->state = BT_CLOSED;
__rfcomm_dlc_close(d, err);
und der frühe Rückkehrwert deckt nur BT_CONNECT, BT_CONFIG, BT_OPEN und BT_CONNECT2. Mit dem Zustand bereits als BT_CLOSED passt dieser Schalter nicht, der Bit wird nie konsultiert, und __rfcomm_dlc_close() fällt durch zu rfcomm_dlc_unlink(), das d->session = NULL setzt.
Daher löscht ein entferntes DISC auf einem verzögerten DLC die Sitzung, während der Bit RFCOMM_DEFER_SETUP gesetzt bleibt. Der nächste recvmsg()-Aufruf schlägt dann die Prüfung und Löschung durch und dereferenziert eine NULL-Sitzung. Kein Timing-Fenster ist erforderlich: Sobald das DISC verarbeitet wurde, erfolgt die Dereferenzierung bedingungslos.
Gib rfcomm_dlc_accept() dieselbe Form wie rfcomm_dlc_open() und rfcomm_dlc_close(): einen exportierten Wrapper, der rfcomm_mutex nimmt und die Sitzung erneut überprüft, um ein __rfcomm_dlc_accept() herum, das die beiden internen Aufrufer weiterhin verwenden, da sie bereits den Mutex halten.
Reproduziert auf einem KASAN + PROVE_LOCKING-Kernel mit einem BR/EDR-Peer, der über /dev/vhci emuliert wird: Der Peer bringt eine ACL-Verbindung hoch, öffnet L2CAP auf dem RFCOMM PSM, startet eine Sitzung, öffnet einen DLC auf einem Kanal, der mit BT_DEFER_SETUP gebunden ist, und sendet DISC nachdem das Socket akzeptiert wurde. Der recv()-Aufruf auf dem akzeptierten Socket trifft dann auf:
Oops: allgemeiner Schutzfehler
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:rfcomm_dlc_accept+0x54/0x350
Call Trace:
rfcomm_sock_recvmsg+0x1cd/0x230
sock_recvmsg+0x166/0x1c0
__sys_recvfrom+0x20d/0x300
0x10 ist der Offset von sock in struct rfcomm_session. Mit diesem Patch wird dieselbe Ausführung mit recv() zurückkehrend 0 und ohne Bericht abgeschlossen, und lockdep bleibt ruhig, was bestätigt, dass rfcomm_mutex weiterhin vor lock_sock auf diesem Pfad gehalten wird, wie es auch auf der Thread-Seite geschieht.
Quelle: suse_csaf, HKCERT (CC BY 3.0 HK) · HKCERT-Einstufung: mittel, Ubuntu Security Notices, Debian LTS Advisories, NVD (NIST), CVE.org (MITRE), ENISA EUVD, Microsoft Security Update Guide, cvelistv5, 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 Versionen | Behoben in | ||
|---|---|---|---|
| Linux | Linux |
|
|
| Red Hat | OpenShift |
|
|
Hersteller und Produkte
Betroffene Betriebssysteme
| Linux | debian | linux | bookworm |
| Linux | ubuntu | linux | jammy |
| Linux | ubuntu | linux | noble |
| Linux | ubuntu | linux | resolute |
| Linux | debian | linux-6.12 | bookworm |
| Linux | ubuntu | linux-aws | jammy |
| Linux | ubuntu | linux-aws | noble |
| Linux | ubuntu | linux-aws | resolute |
| Linux | ubuntu | linux-aws-5.15 | focal |
| Linux | ubuntu | linux-aws-6.8 | jammy |
| Linux | ubuntu | linux-aws-7.0 | noble |
| Linux | ubuntu | linux-aws-fips | jammy |
| Linux | ubuntu | linux-aws-fips | noble |
| Linux | ubuntu | linux-azure | jammy |
| Linux | ubuntu | linux-azure | noble |
| Linux | ubuntu | linux-azure | resolute |
| Linux | ubuntu | linux-azure-5.15 | focal |
| Linux | ubuntu | linux-azure-6.8 | jammy |
| Linux | ubuntu | linux-azure-fde | jammy |
| Linux | ubuntu | linux-azure-fde | noble |
| Linux | ubuntu | linux-azure-fde | resolute |
| Linux | ubuntu | linux-azure-fde-5.15 | focal |
| Linux | ubuntu | linux-azure-fde-6.8 | jammy |
| Linux | ubuntu | linux-azure-fde-7.0 | noble |
Quellen & Referenzen
- git.kernel.orgstable/c/d8d686dd5662a7c4745e4515f1237a9f3b7df181euvd
- git.kernel.orgstable/c/eb71d5a1ea8ff2683e394b48ae3cd676037ab4c2euvd
- git.kernel.orgstable/c/56f0aa75c7640e46397ef73bea251fcbef9150c0euvd
- git.kernel.orgstable/c/362726c9c6e56eea4262109183e49868c39ccd3aeuvd
- git.kernel.orgstable/c/825b95561d7b7c393df9e7bc295451aaeadc3d18euvd
- git.kernel.orgstable/c/d4b1a13b1eff2e80925c7368ffdeaaa50cba93dfeuvd
- git.kernel.orgstable/c/355bfd57ca4ca881c6eb03ca813b440a094b1f44euvd
- git.kernel.orgstable/c/b405c2f96ae2e37375105881890f7738833b1d62euvd
- git.kernel.orgstable/c/43a556b2fd43f2df6dded59c2e26560a27874c24euvd
Ä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).
Eintrag geändertLinux
1 Einzeländerung: Betroffene Versionen (Herausgeber)
Einzeländerung im Original anzeigen
Einzeländerungen dieses Ereignisses im Original der NVD Art Aktion Vorher Nachher Betroffene Versionen (Herausgeber) ergänzt —Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/80xxx/CVE-2026-80819.json">CVE-2026-80819</a>Kennung der Quelle: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Neu erfasstLinux
Beschreibung erfasst oder geändert
Neue Referenzen:- https://git.kernel.org/stable/c/355bfd57ca4ca881c6eb03ca813b440a094b1f44
- https://git.kernel.org/stable/c/362726c9c6e56eea4262109183e49868c39ccd3a
- https://git.kernel.org/stable/c/43a556b2fd43f2df6dded59c2e26560a27874c24
- https://git.kernel.org/stable/c/56f0aa75c7640e46397ef73bea251fcbef9150c0
und 5 weitere Referenzen
11 Einzeländerungen im Original anzeigen
Einzeländerungen dieses Ereignisses im Original der NVD Art Aktion Vorher Nachher Beschreibung ergänzt —In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } and rfcomm_dlc_accept() dereferences the session on its first line: struct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as "called under rfcomm_lock()". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.Betroffene Versionen (Herausgeber) ergänzt —New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/80xxx/CVE-2026-80819.json">CVE-2026-80819</a>Referenz ergänzt —https://git.kernel.org/stable/c/355bfd57ca4ca881c6eb03ca813b440a094b1f44Referenz ergänzt —https://git.kernel.org/stable/c/362726c9c6e56eea4262109183e49868c39ccd3aReferenz ergänzt —https://git.kernel.org/stable/c/43a556b2fd43f2df6dded59c2e26560a27874c24Referenz ergänzt —https://git.kernel.org/stable/c/56f0aa75c7640e46397ef73bea251fcbef9150c0Referenz ergänzt —https://git.kernel.org/stable/c/825b95561d7b7c393df9e7bc295451aaeadc3d18Referenz ergänzt —https://git.kernel.org/stable/c/b405c2f96ae2e37375105881890f7738833b1d62Referenz ergänzt —https://git.kernel.org/stable/c/d4b1a13b1eff2e80925c7368ffdeaaa50cba93dfReferenz ergänzt —https://git.kernel.org/stable/c/d8d686dd5662a7c4745e4515f1237a9f3b7df181Referenz ergänzt —https://git.kernel.org/stable/c/eb71d5a1ea8ff2683e394b48ae3cd676037ab4c2Kennung 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.
<a href="https://intel.neosec.eu/cve/CVE-2026-80819"><img src="https://intel.neosec.eu/badge/cve/CVE-2026-80819.svg" alt="CVE-2026-80819 – NEOSEC Intel" height="20"></a>