Linux Kernel: Verklemmung (Deadlock) (CVE-2026-98069)

Was ist betroffen, was ist zu tun

Im Linux-Kernel wurde folgende Schwachstelle behoben: net/rds: Erwerbe die Fastpath-Sperrschlüssel in rds_conn_shutdown() rds_conn_shutdown() beruhigt die Übertragungs- und Empfangs-Auffüllpfade, indem es auf RDS_IN_XMIT und RDS_RECV_REFILL wartet, bis sie als klar abgetastet werden, und dann den Transport-Shutdown und rds_conn_path_reset() ausführt. Das Abtasten der Bits als klar ist nicht dasselbe wie deren Besitz: im Moment nach dem Zurückkehren von wait_event() kann rds_send_xmit() RDS_IN_XMIT erneut erwerben (oder rds_ib_recv_refill() kann RDS_RECV_REFILL erneut erwerben) und parallel zur Demontage ausgeführt werden.

Aktualisieren Sie Linux Kernel auf Version 5.10.271, Linux Kernel auf Version 5.15.222, Linux Kernel auf Version 6.1.189.

Betroffen

• Linux Kernel lt 2.6.37..5.10.271
• Linux Kernel lt 5.11..5.15.222
• Linux Kernel lt 5.16..6.1.189
• Linux Kernel lt 6.2..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 5.10.271
• Linux Kernel 5.15.222
• Linux Kernel 6.1.189
• 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

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: net/rds: Erwerbe die Fastpath-Sperrschlüssel in rds_conn_shutdown() rds_conn_shutdown() beruhigt die Übertragungs- und Empfangs-Auffüllpfade, indem es auf RDS_IN_XMIT und RDS_RECV_REFILL wartet, bis sie als klar abgetastet werden, und dann den Transport-Shutdown und rds_conn_path_reset() ausführt. Das Abtasten der Bits als klar ist nicht dasselbe wie deren Besitz: im Moment nach dem Zurückkehren von wait_event() kann rds_send_xmit() RDS_IN_XMIT erneut erwerben (oder rds_ib_recv_refill() kann RDS_RECV_REFILL erneut erwerben) und parallel zur Demontage ausgeführt werden. Der Sender überprüft den Verbindungsstatus nach dem Erwerb des Sperrschlüssels erneut, aber diese Überprüfung ist ein klassisches Muster für Speicher-Pufferung: Demontage schreibt den Status und liest das Bit, während der Sender das Bit schreibt und den Status liest. acquire_in_xmit() ist nur eine Erwerbsoperation, daher können auf schwach geordneten Architekturen beide Seiten den Schreibvorgang des anderen verpassen, und der Übertragungspfad wird ausgeführt, während der Transport seine Ringe auf Null setzt (z. B. rds_ib_ring_init()) und rds_send_path_reset() den Übertragungsstatus neu schreibt. Oracle UEK hat denselben Klassen von Abstürzen behoben - ein 14-jähriger Schwanz von BUG_ON()s in rds_ib_sub_signaled(), unerwartete op-codes und NULL-Dereferenzen in rds_ib_send_cqe_handler() während des Failover-Tests - indem der Demontagepfad die Fastpath-Bit-Sperrschlüssel *erwirbt* anstatt sie zu testen ("rds: Stelle sicher, dass der Übertragungspfad und die Verbindungsdemontage nicht parallel laufen"). Der Besitz eines einzelnen Wortes wird durch die RMW-Atomarität entschieden, daher ist keine Quer-Variable-Ordnung erforderlich. Tue dasselbe hier: Nimm beide Sperrschlüssel, bevor du den Transport-Shutdown aufrufst, halte sie über rds_conn_path_reset() und gib sie explizit mit einem Weckruf danach frei. Beide werden mit clear_bit_unlock() freigegeben, sodass die Ring-Neuinitialisierung, die vom Transport-Shutdown und die Neuschreibung des Übertragungsstatus durch rds_send_path_reset() durchgeführt werden, vor dem nächsten acquire_in_xmit() oder acquire_refill() erfolgen, die das Bit als klar sehen. Die Fastpath-Nutzer dieser Bits - rds_send_xmit() und rds_ib_recv_refill() - sind trylock-Stil und verzögern sich, während die Demontage die Sperrschlüssel besitzt, sodass keine neue Sperrabhängigkeit für sie eingeführt wird. rds_tcp_reset_callbacks() ist anders: seit dem vorherigen Patch erwerbt es auch RDS_IN_XMIT und blockiert dabei, sodass sein Warten nun die Demontage umfasst anstatt höchstens eine Sendebatch. Dieser Wartende wird von rds_tcp_accept_one() auf der einheitlichen krdsd-Arbeitswarteschlange ausgeführt und hält rds_tcp_accept_lock und t_conn_path_lock, während er wartet, sodass eine duellierende SYN, die akzeptiert wird, während sein Pfad demontiert wird, die Annahmeverarbeitung für die Dauer der Demontage parkt - für TCP durch die (bis zu 5 s) Entleerungsschleife in rds_tcp_conn_path_shutdown() begrenzt. Ein IB-Pfad hat in rds_ib_conn_path_shutdown() keine runde Obergrenze, aber auch keinen blockierenden Wartenden: rds_tcp_reset_callbacks() ist der einzige blockierende Erwerber dieser Bits und wartet nur auf seinen eigenen TCP-Pfad, und die Fastpaths sind trylock-and-back-off auf beiden Transporten, sodass eine lange IB-Entleerung nur die eigene Beruhigung dieses Pfads verlängert. Das Fenster ist schmal: die Zustandsüberprüfung auf der Annahmeseite muss vor der Demontage bestehen, die den Pfad auf RDS_CONN_DISCONNECTING versetzt. Da krdsd eine einheitliche globale Arbeitswarteschlange ist, wartet alles andere, das dort eingereiht wird - Annahmeverarbeitung für andere Verbindungen und Netzwerknamenräume sowie flush_workqueue(rds_wq) in rds_tcp_listen_stop() während der Namensraum-Demontage - hinter dem geparkten Annahmearbeiter für diese Zeit. Es kann nicht blockieren, obwohl die Wartezeiten aufeinander zeigen: die Demontage blockiert, bis der Inhaber des Bits es freigibt, und der Inhaber kann dieser krdsd-Akzeptarbeiter sein. Der Inhaber beendet ohne etwas zu benötigen, was die Demontage besitzt: die Synchronisation storniert rds_tcp_reset_callbacks() Ausgaben target cp_send_w und cp_recv_w auf der geordneten cp_wq des Pfads, deren einziger Ausführungsslot von dem blockierten cp_down_w selbst besetzt ist, sodass sie höchstens anstehen und ohne Auslöschung storniert werden - eine Abhängigkeit von cp_wq, die geordnet ist, die nun neben diesen Stornierungen vermerkt wird (auf ---abgeschnitten---

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

Quellen & Referenzen

• git.kernel.orgstable/c/7febb113795d5de5b690b208f4b0e64a5fad1201
• git.kernel.orgstable/c/900e96c9749a06833801f60c393aa1d405ea226c
• git.kernel.orgstable/c/1fe627e5db5c3f53a9f9f9c8a66671755d306955
• git.kernel.orgstable/c/813f3582ac7ae9f60f917937d54660e0952d5f2d
• git.kernel.orgstable/c/7f4f21e4439df30d9aca9fb3bac38191a2f34729
• git.kernel.orgstable/c/1f900f585cbb0fbe6aa00c31c9f5bb63ee614456
• git.kernel.orgstable/c/32e21bcf4b5b11454bf57c4bb3bf019b71512ace
• git.kernel.orgstable/c/2e46248e375a516301884719f08b6015c79a6456

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/98xxx/CVE-2026-98069.json">CVE-2026-98069</a>

2. CVE Modified03.10.2026416baaa9-dc9f-4396-8d5f-8c081fb06d67

   • Affected: nachher Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98069.json">CVE-2026-98069</a>
   • Reference: nachher https://git.kernel.org/stable/c/1f900f585cbb0fbe6aa00c31c9f5bb63ee614456
   • Reference: nachher https://git.kernel.org/stable/c/2e46248e375a516301884719f08b6015c79a6456
   • Reference: nachher https://git.kernel.org/stable/c/32e21bcf4b5b11454bf57c4bb3bf019b71512ace

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

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

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

   • Description: nachher In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them ("rds: Make sure transmit path and connection tear-down does not run concurrently"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---
   • Affected: nachher New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98069.json">CVE-2026-98069</a>
   • Reference: nachher https://git.kernel.org/stable/c/1fe627e5db5c3f53a9f9f9c8a66671755d306955
   • Reference: nachher https://git.kernel.org/stable/c/7febb113795d5de5b690b208f4b0e64a5fad1201