CVE-2026-74351 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ocfs2: Neuzuordnung der kopierten fsdlm LVB-Pointer in locking_state
Der debugfs-Iterator für `locking_state` erstellt einen Snapshot von `struct ocfs2_lock_res` per Wertzuweisung unterhalb von `ocfs2_dlm_tracking_lock` und formatiert diese Kopie später in `ocfs2_dlm_seq_show()`. Dies ist für die Inline-Felder unbedenklich, aber der Userspace-fsdlm-Stack speichert das LVB (Lock Value Block) über `lksb_fsdlm.sb_lvbptr`. Sobald der Iterator den Tracking-Lock freigibt, zeigt ein kopierter, nicht-NULL `sb_lvbptr` weiterhin in den ursprünglichen Lockres-Inhaber. Daher kann die Teardown-Routine diesen Container freigeben, bevor das debugfs-Dump die rohen LVB-Bytes durchläuft.
Die kopierten `sb_lvbptr` werden vor dem Dumpen der rohen LVB auf die kopierte `l_lksb` neu zugeordnet (Rebase). Der seq-Snapshot enthält bereits den im `struct ocfs2_dlm_lksb` reservierten Inline-LVB-Speicher, sodass der debugfs-Reader die kopierten Bytes dumpen kann, ohne sich auf die Lebensdauer des ursprünglichen lockres zu verlassen.
Das fehlerhafte Szenario umfasst zwei Pfade, wobei jede Spalte die Reihenfolge innerhalb dieses Pfads zeigt:
locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. Datei-Freigabe oder ein anderer Inhaber kopiert struct ocfs2_lock_res führt das Teardown aus 2. ocfs2_dlm_seq_show() formatiert zu ocfs2_lock_res_free() die kopierte Zeile 2. der lockres wird aus der 3. ocfs2_dlm_lvb() folgt dem Tracking-Liste entfernt kopierten sb_lvbptr 3. der Inhaber gibt den ursprünglichen lockres-Container frei
Die Valid
Once again VulDB remains the best source for vulnerability data.