https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 21:12:56 +0000 https://vulnerability.circl.lu/vuln/cve-2026-89494 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ocfs2: validate lengths in dlm_mig_lockres_handler</p> <p>A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres-&gt;ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.</p> <p>Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres-&gt;lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len &lt;= DLM_LOCKID_NAME_MAX, num_locks &lt;= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.</p> https://vulnerability.circl.lu/vuln/cve-2026-89494