CVE-2026-89494
Zusammenfassung
von VulDB • 12.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ocfs2: Validierung der Längen in dlm_mig_lockres_handler
Ein Knoten, der eine DLM_MIG_LOCKRES-Nachricht empfängt, vertraut mehreren Feldern des von einem Peer bereitgestellten `dlm_migratable_lockres`, ohne diese zu validieren. Die Werte für `num_locks` und `lockname_len` werden nur auf der sendenden Seite begrenzt, und die Nachricht wird niemals daraufhin überprüft, ob sie tatsächlich `num_locks` Einträge vom Typ `migratable_lock` enthält. Infolgedessen durchläuft `dlm_process_recovery_data()` den Bereich `mres->ml[0..num_locks)` über den mit `kmalloc(data_len)` kopierten Teil der Nachricht hinaus (ein Out-of-Bounds-Lesezugriff, der in einem BUG_ON-Panic endet), und `dlm_init_lockres()` kopiert `lockname_len` Bytes in das fest dimensionierte 32-Byte-große Slab-Objekt von o2dlm_lockname (ein Heap-Out-of-Bounds-Schreibzugriff). Beide sind für jeden Knoten im Domain erreichbar.
Diese Felder sollten unmittelbar nach dem Aufruf von `dlm_grab()` validiert werden, bevor sie anderweitig verwendet werden – einschließlich des Fehlerpfads bei nicht beigetretenem Status, der bereits `mres->lockname` mit der unbeschränkten Länge `lockname_len` als `%.*s`-Präzision ausgibt. Die Nachricht ist abzulehnen, es sei denn, `lockname_len <= DLM_LOCKID_NAME_MAX`, `num_locks <= DLM_MAX_MIGRATABLE_LOCKS` (die vom Absender bereits behauptete Obergrenze) und der Payload ist groß genug, um die beanspruchten Lock-Einträge aufzunehmen. Konforme Recovery- und Migrationsnachrichten bleiben davon unberührt.
If you want to get best quality of vulnerability data, you may have to visit VulDB.