Linux Kernel: Sicherheitslücke (CVE-2026-97941)

Was ist betroffen, was ist zu tun

Im Linux-Kernel wurde folgende Schwachstelle behoben: mm/slab: In `__slab_try_return_freelist()` `n->list_lock` annehmen, um eine Racebedingung zu vermeiden. Der Commit `ba7425312607` ("mm, slab: add an optimistic `__slab_try_return_freelist()`") ging fälschlicherweise davon aus, dass niemand ein Objekt an den Slab freigegeben hat, solange `slab->freelist` NULL ist und `cmpxchg` erfolgreich ist.

Aktualisieren Sie Linux Kernel auf Version 7.2.7, Linux Kernel auf Version 7.3.

Betroffen

• Linux Kernel lt 7.2..7.2.7

Behoben in

• Linux Kernel 7.2.7
• Linux Kernel 7.3

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

Metriken

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: mm/slab: In `__slab_try_return_freelist()` `n->list_lock` annehmen, um eine Racebedingung zu vermeiden. Der Commit `ba7425312607` ("mm, slab: add an optimistic `__slab_try_return_freelist()`") ging fälschlicherweise davon aus, dass niemand ein Objekt an den Slab freigegeben hat, solange `slab->freelist` NULL ist und `cmpxchg` erfolgreich ist. Wie jedoch von Hyunwoo Kim [1] berichtet, könnten andere CPUs ein Objekt an den Slab freigegeben haben, den Slab in die partielle Liste eingefügt, dann ein Objekt aus dem Slab zugewiesen und dabei sein, den Slab unter `n->list_lock` aus der Liste zu entfernen. Da `__refill_objects_node()` den Slab außerhalb von `n->list_lock` auf `pc.slabs` zurücksetzt, könnte es den Slab in diese Liste einfügen, während der Slab gleichzeitig aus `n->partial` entfernt wird. Dies führte zu einer Listenbeschädigung [1]: Listenbeschädigung. `next->prev` sollte `prev` sein (ffff888100000248), war aber `dead000000000122` (next=ffffea000416e410). Kernel-Bug in `lib/list_debug.c:29!` Oops: ungültiger Opcode: 0000 [#1] SMP NOPTI CPU: 1 UID: 65534 PID: 144 Comm: poc Nicht verunreinigt 7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy) RIP: 0010:__list_add_valid_or_report+0x80/0xd0 ... Aufrufverfolgung: alloc_from_new_slab+0x183/0x300 ___slab_alloc+0x31c/0x890 __kmalloc_noprof+0x3d4/0x800 lsm_blob_alloc+0x2d/0x50 security_msg_msg_alloc+0x26/0x90 load_msg+0x1aa/0x210 do_msgsnd+0x91/0x800 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Kernel-Panik - nicht synchronisieren: Fataler Ausnahme Dies ist ein klassisches ABA-Problem, bei dem `cmpxchg` erfolgreich ist, aber der Zustand sich seit `__refill_objects_node()` änderte, als der freelist vom Slab genommen wurde. Wie Vlastimil Babka erwähnte [2], sollte es selten sein, mehr als einen Slab zurückzugeben (aufgrund des racy reads von `slab->counters` in `get_partial_node_bulk()`). Daher wird anstatt zusätzliche Komplexität einzuführen, `n->list_lock` im schlimmsten Fall zweimal erworben und freigegeben. Den Slab direkt zur partiellen Liste zurückgeben und `n->list_lock` über `cmpxchg` und `add_partial()` halten. Dies ähnelt der ursprünglichen Version des Commits `ba7425312607` [3]. Dies reicht aus, um die Racebedingung zu vermeiden, da die Listenmanipulation durch `n->list_lock` serialisiert wird. Dabei wird die `unlikely()`-Hinweis jetzt wieder eingeführt, da die Bedingung unwahrscheinlich ist.

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

Quellen & Referenzen

• git.kernel.orgstable/c/570a6aaf6b52c6ec098f4811cdb52b1496f13d15
• git.kernel.orgstable/c/4a724bcf5d703e18957397914d79156fa2cf1174

Re-Analyse & Statuswechsel

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

1. CVE Modified19.10.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

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

2. CVE Modified25.09.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

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

3. New CVE Received25.09.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

   • Description: nachher In the Linux kernel, the following vulnerability has been resolved: mm/slab: take n->list_lock in __slab_try_return_freelist() to avoid race Commit ba7425312607 ("mm, slab: add an optimistic __slab_try_return_freelist()") incorrectly assumed that nobody has freed an object to the slab as long as slab->freelist is NULL and cmpxchg succeeds. However, as reported by Hyunwoo Kim [1], other CPUs might have freed an object to the slab, insert the slab to the partial list, then allocated an object from the slab, and be in the middle of removing the slab from the list under n->list_lock. Since __refill_objects_node() puts the slab back on pc.slabs outside n->list_lock, it might insert the slab into that list while the slab is concurrently being removed from n->partial. This led to a list corruption [1]: list_add corruption. next->prev should be prev (ffff888100000248), but was dead000000000122. (next=ffffea000416e410). kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 UID: 65534 PID: 144 Comm: poc Not tainted 7.2.0-16172-gcf72cbb39da8-dirty #1 PREEMPT(lazy) RIP: 0010:__list_add_valid_or_report+0x80/0xd0 ... Call Trace: alloc_from_new_slab+0x183/0x300 ___slab_alloc+0x31c/0x890 __kmalloc_noprof+0x3d4/0x800 lsm_blob_alloc+0x2d/0x50 security_msg_msg_alloc+0x26/0x90 load_msg+0x1aa/0x210 do_msgsnd+0x91/0x800 do_syscall_64+0x109/0x5d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Kernel panic - not syncing: Fatal exception This is a classic ABA problem where cmpxchg succeeds but the state has changed since __refill_objects_node() took the freelist from the slab. As Vlastimil Babka mentioned [2], it should be rare to return more than one slab (due to the racy read of slab->counters in get_partial_node_bulk()). Therefore, instead of introducing additional complexity, acquire and release n->list_lock twice in the worst case. Return the slab directly to the partial list and hold n->list_lock across the cmpxchg and add_partial(). This is similar to the initial version of commit ba7425312607 [3]. This is enough to avoid the race as the list manipulation is serialized by n->list_lock. While at it, bring back unlikely() hint now that the condition is unlikely.
   • Affected: nachher New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97941.json">CVE-2026-97941</a>
   • Reference: nachher https://git.kernel.org/stable/c/4a724bcf5d703e18957397914d79156fa2cf1174
   • Reference: nachher https://git.kernel.org/stable/c/570a6aaf6b52c6ec098f4811cdb52b1496f13d15