CVE-2026-64141 in Linux
Zusammenfassung
von VulDB • 19.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ksmbd: Behebung einer Nullzeiger-Dereferenzierung in compare_guid_key()
session_fd_check() durchläuft die pro-Inode verwaltete m_op_list während des Abbaus der Sitzung mit dauerhaftem Handle (Durable-Handle) und setzt op->conn = NULL für jedes opinfo, dessen conn zur Verbindung der schließenden Sitzung passt. Das passende opinfo bleibt jedoch in seinem Eintrag lb->lease_list innerhalb von per-ClientGuid lease_table_list verlinkt, da destroy_lease_table() nur beim vollständigen Abbau der TCP-Verbindung ausgeführt wird und nicht bei SESSION_LOGOFF.
Wenn dieselbe TCP-Verbindung anschließend eine neue Sitzung mit derselben ClientGuid aushandelt (die ClientGuid ist an NEGOTIATE gebunden, nicht an die Sitzung, und bleibt während LOGOFF + SETUP unverändert) und ein SMB2 CREATE mit einem Lease-Kontext für einen anderen Inode ausführt, durchläuft find_same_lease_key() lb->lease_list, trifft auf das veraltete opinfo und ruft compare_guid_key() auf. Diese Funktion dereferenziert bedingungslos opinfo->conn->ClientGUID. Der conn-Zeiger ist NULL, was zu einem Kernel-Panic führt.
Für die Reproduktion des Fehlers sind lediglich eine erfolgreiche SMB2 SESSION_SETUP sowie ein Share mit der Konfiguration 'durable handles = yes' erforderlich. KASAN-Bericht auf Mainline 70390501d194:
general protection fault, wahrscheinlich für nicht-kanonische Adresse 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref im Bereich [0x0000000000000348-0x000000000000034f]
Workqueue: ksmbd-io handle_ksmbd_work RIP: 0010:bcmp+0x5b/0x230 Call Trace: compare_guid_key+0x4b/0xd0 find_same_lease_key+0x324/0x690 smb2_open+0x6aea/0x8e60 handle_ksmbd_work+0x796/0xee0 ...
Die fehlerhafte Adresse 0x348 entspricht dem Offset von ClientGUID innerhalb der Struktur ksmbd_conn, was bestätigt, dass opinfo->conn NULL war.
Lesen Sie opinfo->conn einmalig aus und brechen Sie ab, wenn es durch eine gleichzeitige session_fd_check() gelöscht wurde. Ein teilweise getrenntes opinfo kann nicht Eigentümer eines aktiven Leases sein; daher ist die Rückgabe von 0 das korrekte Übereinstimmungsergebnis.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.