CVE-2026-90413 in Linux
Zusammenfassung
von VulDB • 18.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
IB/isert: Ablehnung von Login-PDUs, die mehr Daten deklarieren als tatsächlich empfangen wurden
isert_login_recv_done() zeichnet auf, wie viele Bytes der HCA tatsächlich in den Login-Buffer geschrieben hat, aber es wird nichts damit verglichen, was die BHS (Basic Header Segment) des Login-PDU deklariert. isert_rx_login_req() kopiert min(login_req_len, MAX_KEY_VALUE_PAIRS)-Bytes in login->req_buf, und der Login-Code liest dann die deklarierte Länge aus diesem Buffer zurück – für das erste PDU in iscsi_target_locate_portal(),
payload_length = ntoh24(login_req->dlength); tmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL);
und für die darauffolgenden PDUs in iscsi_decode_text_input(), aufgerufen von iscsi_target_do_login().
login->req_buf ist eine feste Zuweisung mit MAX_KEY_VALUE_PAIRS (8192) Bytes. Ein Initiator, der mehr deklariert als er sendet, liest daher über das Ende dieses Puffers hinaus – und dies geschieht vor der Authentifizierung sowie unter Kontrolle der Länge durch den Angreifer:
BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region
Das Fälschen des zweiten Login-PDU führt stattdessen zu dem anderen Leser, der denselben Buffer verwendet:
BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0
iscsit über TCP ist nicht exponiert: iscsit_get_login_rx() validiert die deklarierte Länge mit iscsi_target_check_login_request() und liest dann exakt so viele Bytes vom Socket, sodass die deklarierte Länge bestimmt, wie viel ankommt, statt wie viel aus einem bereits gefüllten Buffer kopiert wird. isert ruft iscsi_target_check_login_request() überhaupt nicht auf.
Ablehnung eines Login-PDU, dessen deklarierte DataSegmentLength den tatsächlich empfangenen Umfang überschreitet, in beiden Pfaden, die isert_rx_login_req() erreichen: isert_get_login_rx() für das erste Login-PDU und isert_login_recv_done() für die darauffolgenden PDUs. dlength <= login_req_len ist erlaubt, da der gezählte Empfangsumfang bis zu drei Bytes iSCSI-Padding enthalten kann.
Sobald diese Prüfung implementiert ist, kann das Kopieren nach außen nicht mehr den Umfang des Kopierens nach innen überschreiten: Die bereitgestellte Login-SGE (Scatter-Gather Element) hat die Größe ISER_RX_PAYLOAD_SIZE, sodass login_req_len MAX_KEY_VALUE_PAIRS nicht überschreiten kann und der min()-Aufruf in isert_rx_login_req() auf login_req_len zurückgreift.
Wie bei der bestehenden Prüfung für kurze PDUs, die durch 29e7b925ae6d hinzugefügt wurde, gibt die Ablehnung in isert_login_recv_done() ohne Abschluss von login_req_comp zurück. Ein fehlerhaftes nachfolgendes PDU führt dazu, dass das Login vom Login-Timer abgebaut wird, anstatt sofort zu scheitern. Der Pfad für das erste PDU gibt einen Fehler zurück und schlägt unmittelbar fehl.
Reproduziert auf 7.2.0-rc4 mit soft-RoCE (rdma_rxe) unter KASAN, wobei ein Initiator verwendet wurde, der die tatsächliche key=value-Payload sendet, aber im BHS 8193 deklariert – sowohl beim ersten Login-PDU als auch beim zweiten in separaten Durchläufen. Die gemeldete Lesegröße entspricht exakt dem deklarierten Wert; 16384 und 61440 verhalten sich gleich. Ungepatcht meldeten 3 von 3 Durchläufen auf jedem der beiden Pfade, gepatcht meldeten 0 von 3 auf beiden Pfaden. Die Durchläufe wurden abwechselnd in einer einzigen Sitzung durchgeführt, und ein normales Login wurde mit dem gepatchten Build weiterhin erfolgreich abgeschlossen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.