CVE-2026-89495 in Linux
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ocfs2: Begrenzung von namelen in dlm_migrate_request_handler
Patch-Serie „ocfs2/dlm: Begrenzung peer-kontrollierter Längen im o2dlm“.
Die Empfangs-Handler von o2dlm vertrauen den u8-Längen- und Zählfeldern aus dem Netzwerkstrom, ohne diese zu begrenzen. Daher kann ein Knoten in einem DLM-Domänenbereich jeden anderen Knoten durch eine fehlerhafte Nachricht beschädigen oder zum Absturz bringen (Panic). Drei Defekte:
- dlm_migrate_request_handler() übergibt migrate->namelen ungeprüft an dlm_init_mle(), das es mit memcpy() in den 32-Byte großen mname[]-Array eines
o2dlm_mle-Slab-Objekts kopiert: ein Heap-Out-of-Bounds-Write von bis zu ~215 vom Angreifer kontrollierten Bytes.
- dlm_mig_lockres_handler() übergibt mres->lockname_len ungeprüft an dlm_init_lockres(), das es mit memcpy() in den 32-Byte großen o2dlm_lockname-Slab-Objekt kopiert: ein Heap-Out-of-Bounds-Write von bis zu ~223 Bytes.
- derselbe Handler vertraut mres->num_locks, ohne zu prüfen, ob die Nachricht groß genug ist, um diese Anzahl an Einträgen aufzunehmen; daher läuft dlm_process_recovery_data() mit mres->ml[] über den kmalloc(data_len)-Puffer hinaus und löst einen BUG_ON aus (ein Out-of-Bounds-Read, der in einem Panic endet).
Die anderen o2dlm-Empfangs-Handler lehnen bereits zu große Namen ab; die Migrations- und Wiederherstellungs-Handler haben dies seit der Einführung des DLM unterlassen (siehe Fixes-Tags). Patch 1 begrenzt namelen; Patch 2 validiert lockname_len, num_locks und die Payload-Größe. Konforme Recovery- und Migrationsdatenverkehr bleibt unverändert.
o2net authentifiziert Peers nur über den DLM-Domänenschlüssel, sodass jeder Knoten, der dem Domänenbereich beigetreten ist – einschließlich eines kompromittierten oder böswilligen Mitglieds – diese Nachrichten senden kann. Es gibt keinen lokalen Trigger; der Angreifer muss bereits Mitglied des Clusters sein.
Jede Schwachstelle wurde unter KASAN mit einem Out-of-Tree-Modul bestätigt, das sie exakt nachbildet: ein kmem_cache/kmalloc in der tatsächlichen Zielgröße, gefolgt von demselben ungebremsten memcpy/Loop: Slab-Out-of-Bounds Write für die beiden Writes, Read für den Recovery-Durchlauf und ein Panic. Ein Userspace-AddressSanitizer-Build zeigt identische Fehler unter -m32 und -m64. Bereinigte Logs sind auf Anfrage verfügbar.
Ich habe dies am 2026-06-20 privat an [email protected] und die ocfs2-Maintainer gemeldet; da nach der üblichen Embargo-Zeit keine Antwort erfolgte, veröffentliche ich den Fix öffentlich. Ich unterliege keiner Embargo-Pflicht.
Dieser Patch (von 2):
Ein Knoten, der eine DLM_MIGRATE_REQUEST-Nachricht empfängt, vertraut der vom Peer angegebenen Namenskennungslänge (migrate->namelen), ohne diese zu begrenzen. dlm_init_mle() kopiert dann so viele Bytes in den festen mname[]-Array mit der Größe DLM_LOCKID_NAME_MAX eines o2dlm_mle-Slab-Objekts, sodass eine fehlerhafte Nachricht von einem Cluster-Peer das Slab-Objekt um bis zu ~215 Bytes überläuft: ein Heap-Out-of-Bounds-Write mit vom Angreifer kontrollierten Daten, der für jeden Knoten in der Domäne erreichbar ist.
Lehnen Sie einen zu großen Namen ab, so wie es dlm_master_request_handler() und die anderen o2dlm-Empfangs-Handler bereits tun; der Migrations-Handler lässt diese Prüfung vollständig weg. Konforme Nachrichten bleiben unverändert.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.