In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ocfs2: bound namelen in dlm_migrate_request_handler<\/p>\n
Patch series “ocfs2\/dlm: bound peer-controlled lengths in the o2dlm”.<\/p>\n
The o2dlm receive handlers trust u8 length and count fields from the wire
\nwithout bounding them, so a node in a DLM domain can corrupt or panic any
\nother node with a malformed message. Three defects:<\/p>\n
– dlm_migrate_request_handler() passes migrate->namelen unchecked to
\n dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
\n o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
\n attacker-controlled bytes.<\/p>\n
– dlm_mig_lockres_handler() passes mres->lockname_len unchecked to
\n dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
\n slab object: a heap out-of-bounds write of up to ~223 bytes.<\/p>\n
– the same handler trusts mres->num_locks without checking that the
\n message is large enough to hold that many entries, so
\n dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len)
\n copy and trips a BUG_ON (an out-of-bounds read ending in a panic).<\/p>\n
The other o2dlm receive handlers already reject an oversized name; the
\nmigration and recovery handlers have omitted it since the DLM was added
\n(see the Fixes tags). Patch 1 bounds namelen; patch 2 validates
\nlockname_len, num_locks, and the payload size. Conforming recovery and
\nmigration traffic is unaffected.<\/p>\n
o2net authenticates peers only by the DLM domain key, so any node that has
\njoined the domain — including a compromised or malicious member — can
\nsend these messages. There is no local trigger; the attacker must already
\nbe a member of the cluster.<\/p>\n
Each sink was confirmed under KASAN with an out-of-tree module mirroring
\nit exactly — a kmem_cache\/kmalloc of the real destination size, then the
\nsame unclamped memcpy\/loop: slab-out-of-bounds Write for the two writes,
\nRead for the recovery walk, and a panic. A userspace AddressSanitizer
\nbuild faults identically under -m32 and -m64. Scrubbed logs are available
\non request.<\/p>\n
I reported this privately to security@kernel.org and the ocfs2 maintainers
\non 2026-06-20; with no response after the standard embargo period I am
\nposting the fix publicly. I have no embargo requirement.<\/p>\n
This patch (of 2):<\/p>\n
A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied
\nname length (migrate->namelen) without bounding it. dlm_init_mle() then
\ncopies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[]
\narray of an o2dlm_mle slab object, so a malformed message from a cluster
\npeer overflows the slab object by up to ~215 bytes: a heap out-of-bounds
\nwrite of attacker-controlled data, reachable by any node in the domain.<\/p>\n
Reject an oversized name, the way dlm_master_request_handler() and the
\nother o2dlm receive handlers already do; the migration handler omits the
\ncheck entirely. Conforming messages are unaffected.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ocfs2: bound namelen in dlm_migrate_request_handler<\/p>\n
Patch series “ocfs2\/dlm: bound peer-controlled lengths in the o2dlm”.<\/p>\n
The o2d<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21417","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}