CVE-2026-98069 in Linux
Zusammenfassung
von VulDB • 25.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/rds: Erwerben der Fastpath-Sperren in rds_conn_shutdown()
rds_conn_shutdown() beruhigt die Sende- und Empfangs-Auffüllpfade, indem es darauf wartet, dass RDS_IN_XMIT und RDS_RECV_REFILL als gelöscht (clear) gemeldet werden, und führt anschließend den Transport-Shutdown sowie rds_conn_path_reset() aus. Das bloße Abfragen der Bits auf „gelöscht“ ist nicht gleichbedeutend mit dem Besitz derselben: Im Moment nach Rückgabe von wait_event() kann rds_send_xmit() RDS_IN_XMIT (oder rds_ib_recv_refill() kann RDS_RECV_REFILL) erneut erwerben und parallel zum Abbau ausgeführt werden.
Der Sender überprüft den Verbindungsstatus zwar nach dem Erwerben der Sperre neu, doch diese Überprüfung entspricht einem klassischen Store-Buffering-Muster: Der Abbau schreibt den Status und liest das Bit, während der Sender das Bit schreibt und den Status liest. acquire_in_xmit() ist lediglich eine Acquire-Operation; daher können auf Architekturen mit schwacher Speicherordnung (weakly ordered) beide Seiten die Schreibzugriffe des jeweils anderen verpassen, wodurch der Sende-Pfad ausgeführt wird, während der Transport seine Ringe löscht (z. B. rds_ib_ring_init()) und rds_send_path_reset() den Sendestatus darüber hinweg überschreibt.
Oracle UEK hat dieselbe Klasse von Abstürzen behoben – eine 14-jährige Kette von BUG_ON()-Aufrufen in rds_ib_sub_signaled(), unerwarteten Op-Codes sowie NULL-Dereferenzierungen in rds_ib_send_cqe_handler() während Failover-Tests –, indem der Abbau-Pfad die Fastpath-Bit-Sperren *erwirbt*, anstatt sie lediglich zu testen („rds: Stellen Sie sicher, dass Sende-Pfad und Verbindungsabbau nicht parallel ausgeführt werden“). Der Besitz eines einzelnen Wortes wird durch RMW-Atomizität (Read-Modify-Write) entschieden, sodass keine cross-variable ordering erforderlich ist.
Gehen Sie hier ebenso vor: Erwerben Sie beide Sperren, bevor der Transport-Shutdown aufgerufen wird; halten Sie diese während rds_conn_path_reset() und geben Sie sie anschließend explizit mit einem Wake-up frei. Beide werden mit clear_bit_unlock() freigegeben, sodass die Ring-Neuinitialisierung durch den Transport-Shutdown sowie das Überschreiben des Sendestatus durch rds_send_path_reset() vor dem Sichtbarwerden als gelöscht für jeden nachfolgenden acquire_in_xmit()- oder acquire_refill()-Aufruf geordnet sind.
Die Fastpath-Nutzer dieser Bits – rds_send_xmit() und rds_ib_recv_refill() – arbeiten im Trylock-Stil und weichen zurück, solange der Abbau die Sperren besitzt; es wird also keine neue Abhängigkeit für sie eingeführt. rds_tcp_reset_callbacks() ist anders: Seit dem vorherigen Patch erwirbt auch es RDS_IN_XMIT und blockiert dabei; seine Wartezeit erstreckt sich somit über den gesamten Abbau hinweg, statt sich auf höchstens einen Sendebatch zu beschränken. Dieser Wartende wird von rds_tcp_accept_one() im single-threaded krdsd workqueue ausgeführt und hält rds_tcp_accept_lock sowie t_conn_path_lock während der Wartezeit; ein konkurrierender SYN-Request, der angenommen wird, während sein Pfad abgebaut wird, parkt die Annahmeverarbeitung für die Dauer des Abbaus – bei TCP begrenzt durch den (bis zu 5 s dauernden) Drain-Loop in rds_tcp_conn_path_shutdown(). Ein IB-Pfad-Drain in rds_ib_conn_path_shutdown() hat keine Rundenzapfengrenze, aber auch keinen blockierenden Wartenden: rds_tcp_reset_callbacks() ist der einzige blockierende Erwerber dieser Bits und wartet nur auf seinen eigenen TCP-Pfad; die Fastpaths sind bei beiden Transports Trylock-and-Back-off, sodass ein langer IB-Drain lediglich den Quiesce-Zustand dieses einen Pfads verlängert. Das Zeitfenster ist schmal: Die Statusprüfung auf der Annahmeseite muss erfolgreich sein, bevor der Abbau den Pfad in RDS_CONN_DISCONNECTING versetzt.
Da krdsd ein einzelner globaler workqueue ist, warten alle anderen dort eingereihten Aufgaben – die Annahmeverarbeitung für andere Verbindungen und Netzwerk-Namensräume sowie das flush_workqueue(rds_wq) in rds_tcp_listen_stop() während des Abbau von Namensräumen – hinter dem geparkten Annahme-Arbeiter für diese Zeit. Es kann nicht zu einem Deadlock kommen, obwohl die Wartezeiten sich gegenseitig referenzieren: Der Abbau blockiert, bis der Inhaber des Bits ihn freigibt, und der Inhaber könnte dieser krdsd-Annahme-Arbeiter sein. Der Inhaber beendet seine Aufgabe ohne Abhängigkeit von Ressourcen, die dem Abbau gehören: Die Synchronisierung durch das Cancelln von rds_tcp_reset_callbacks() zielt auf cp_send_w und cp_recv_w im geordneten cp_wq des Pfads ab; dessen einziger Ausführungsslot ist vom blockierten cp_down_w selbst belegt, sodass diese Aufgaben höchstens ausstehen und ohne Flush gekappt werden – eine Abhängigkeit davon, dass cp_wq geordnet ist, die nun neben diesen Cancell-Operationen vermerkt wird (auf ---abgeschnitten---
If you want to get best quality of vulnerability data, you may have to visit VulDB.