CVE-2026-64320

Beschreibung

Im Linux-Kernel wurde die folgende Sicherheitsanfälligkeit behoben: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page nvmet execute disc get log page() validiert nur die dword-Ausrichtung des vom Host bereitgestellten Log Page Offsets (lpo). Der 64-Bit-Offset wird dann zu einem kleinen kzalloc'd-Buffer hinzugefügt, der die Discovery-Logseite enthält, und das Ergebnis wird direkt an nvmet copy to sgl() weitergeleitet, der memcpy()s data len-Bytes ohne quellseitige gebundene Prüfung an den Host weitergeleitet: u64 offset = nvmet get log page offset(req->cmd); /* 64-Bit-Host */ size t data len = nvmet get log page len(req->cmd); /* 32-Bit-Host */ ... wenn (offset & 0x3) { ... } /* nur */ ... alloc len = sizeof(*hdr) + entry size * discovery log entries(req); buffer = kzalloc(alloc len, GFP KERNEL); ... status = nvmet copy to sgl(req, 0, buffer + offset, data len); Der Discovery-Controller ist unauthen Mit einer Discovery-Log-Seite von ~1 KiB liest ein Angreifer, der bis zu 4 KiB anfordert, beginnend mit Offset == alloc len, die nächste Plattenseite aus und erhält ihren Inhalt über den Stoff zurück (ein empirischer Lauf auf einem Standard-Nvmet-TCP-Loopback-Ziel hat 81 kanonische Kernel-Pointer in einer Get Log Page-Antwort durchgesickert). Durch das Zeigen des Offsets auf den nicht zugeordneten Kernelspeicher wird der In-Kernel-Memcpy gestört und stattdessen der Zielhost abgestürzt (oder panisch, auf panic on oops=1). Das angreifergesteuerte quellenseitige Offsetmuster "nvmet copy to sgl(req, 0, buffer + ATTACKER OFFSET, ...)" ist einzigartig für nvmet execute disc get log page in der gesamten nvmet-Codebasis: jeder andere Get Log Page-Handler in admin-cmd.c ignoriert entweder lpo (und startet jede Antwort stillschweigend bei Offset 0) oder verfolgt einen lokalen Ziel-Offset mit einem festen Quellzeiger. Validieren Sie den vom Host bereitgestellten Offset gegen die Log-Seitengröße, begrenzen Sie die Kopienlänge auf das, was tatsächlich verfügbar ist, und füllen Sie den Rest des Host-Transferpuffers auf Null. Der Zero-Fill stimmt mit dem vorhandenen Short-Response-Muster in nvmet execute get log changed ns() (admin-cmd.c) überein und verhindert das Auslaufen von Transport-SGL-Inhalten, wenn der Host nach mehr Bytes fragt, als die Protokollseite enthält.

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren: linux linux kernel.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.