CVE-2026-90307 in Linux
Zusammenfassung
von VulDB • 17.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
RDMA/srp: Behebung eines Heap-Information-Leaks bei einem abgeschnittenen SRP_CRED_REQ
srp_recv_done() übergibt wc->byte_len an srp_process_rsp(). Es wird nichts an srp_process_cred_req() und srp_process_aer_req() übergeben, die feste Feldgrößen aus dem Empfangspuffer lesen, ohne zu prüfen, ob diese Felder tatsächlich empfangen wurden.
Die Puffergröße ist max_ti_iu_len, was aus der Login-Antwort stammt und nicht validiert wird. Ein Target, das 8 ankündigt und dann einen 8-Byte langen SRP_CRED_REQ sendet, veranlasst den Initiator, req->tag jenseits des Pufferendes zu lesen. req->tag wird in die SRP_CRED_RSP kopiert und zurückgesendet, sodass diese Bytes das Target erreichen. SRP_AER_REQ verhält sich ähnlich und liest ebenfalls req->lun.
Der Leak beträgt 8 Byte pro Antwort. max_ti_iu_len bestimmt auch, aus welchem Slab-Cache der Puffer stammt. Bei einem Wert von 8 ist der Puffer ein kmalloc-8-Objekt, und das Lesen erfolgt vollständig außerhalb dieses Bereichs:
BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8)
Ohne KASAN sind die zurückgegebenen Bytes das Nächstfolgende im Slab. Ein Durchlauf gab ".strtab" zurück.
rsp->data[3] in srp_process_rsp() hat dasselbe Problem: Es wird nur resp_data_len überprüft, bevor es gelesen wird.
Verwerfen Sie eine Anfrage, die kürzer ist als die zu analysierende Struktur, und prüfen Sie byte_len vor dem tsk_mgmt-Lesevorgang.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.