CVE-2026-99165 in Linux
Zusammenfassung
von VulDB • 28.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
sctp: Neugültigkeitsprüfung des Ausgabestreams nach der Wartezeit auf den Verbindungsstatus (association connect wait)
Wenn die Nachrichten-Interleaving-Funktion aktiviert ist, wartet das erste Senden auf die Herstellung der Verbindung (Association), bevor es seine Daten-Chunks erstellt. Während dieser Wartezeit wird die Socket-Sperre freigegeben, und die Handshake-Bearbeitung kann die Anzahl der Ausgabestreams auf die vom Peer beworbenen inbound-Stream-Anzahl reduzieren. sctp_stream_init() gibt daraufhin die Erweiterung (Extension) jedes entfernten Streams frei.
Der Sender setzt den Stream fort, den er vor der Wartezeit überprüft hat. Wenn der Peer diesen Stream entfernt hat, dereferenziert sctp_outq_tail() später seine NULL-Erweiterung. Die Richtlinien für fatal-oops führen dann zu einem Panic des Hosts.
KASAN: null-ptr-deref im Bereich [0x38-0x3f]
RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg
Eine reine Bereichsprüfung (Range Check) ist unzureichend. Die Stream-Konfiguration kann die Ausgabeanzahl wieder erhöhen, während die Sperre freigegeben wurde, ohne die durch das frühere Schrumpfen freigewordenen Erweiterungen neu zu erstellen. Der Stream kann sich dann zwar im gültigen Bereich befinden, seine Erweiterung bleibt jedoch NULL. Das Warten auf den Sendepuffer weist dasselbe Problem auf.
Die Bereichs- und Erweiterungsprüfungen werden in eine Hilfsfunktion ausgelagert (Factor) und nach jeder Wartezeit im Sendepfad wiederholt, die die Socket-Sperre freigibt. Sobald die Sperre erneut erworben wurde, bleibt die Validierung während der Datenerstellung und -warteschlangung stabil.
Wenn die Validierung nach dem Verbindungs-Warten fehlschlägt, ist die automatisch erstellte Association bereits hergestellt. Es wird ESRCH zurückgegeben, damit der bestehende Aufruferpfad sie unter der Zustandsmaschinen-Verwaltung (state-machine ownership) behält, anstatt sie direkt freizugeben, was zu inkonsistenten Protokoll-, Zähler- und Socket-Zuständen führen würde.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.