In the Linux kernel, the following vulnerability has been resolved:
ocfs2: bound namelen in dlm_migrate_request_handler
Patch series "ocfs2/dlm: bound peer-controlled lengths in the o2dlm".
The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message. Three defects:
-
dlm_migrate_request_handler() passes migrate->namelen unchecked to
dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
attacker-controlled bytes.
-
dlm_mig_lockres_handler() passes mres->lockname_len unchecked to
dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
slab object: a heap out-of-bounds write of up to ~223 bytes.
-
the same handler trusts mres->num_locks without checking that the
message is large enough to hold that many entries, so
dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len)
copy and trips a BUG_ON (an out-of-bounds read ending in a panic).
The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags). Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size. Conforming recovery and
migration traffic is unaffected.
o2net authenticates peers only by the DLM domain key, so any node that has
joined the domain -- including a compromised or malicious member -- can
send these messages. There is no local trigger; the attacker must already
be a member of the cluster.
Each sink was confirmed under KASAN with an out-of-tree module mirroring
it exactly -- a kmem_cache/kmalloc of the real destination size, then the
same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes,
Read for the recovery walk, and a panic. A userspace AddressSanitizer
build faults identically under -m32 and -m64. Scrubbed logs are available
on request.
I reported this privately to security@kernel.org and the ocfs2 maintainers
on 2026-06-20; with no response after the standard embargo period I am
posting the fix publicly. I have no embargo requirement.
This patch (of 2):
A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied
name length (migrate->namelen) without bounding it. dlm_init_mle() then
copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[]
array of an o2dlm_mle slab object, so a malformed message from a cluster
peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds
write of attacker-controlled data, reachable by any node in the domain.
Reject an oversized name, the way dlm_master_request_handler() and the
other o2dlm receive handlers already do; the migration handler omits the
check entirely. Conforming messages are unaffected.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - DLM_MIGRATE_REQUEST is received and dispatched by the ocfs2 o2net TCP cluster transport, so dlm_migrate_request_handler() is reached through network protocol messages from a peer node.
AC:L - A cluster peer can send a crafted DLM_MIGRATE_REQUEST with attacker-chosen namelen; dlm_init_mle() then memcpy()s that length into the 32-byte mname[] with no race or other condition outside the attacker's control.
PR:N - o2net gates peers by configured node IP, heartbeat, and the DLM domain key, with no user authentication or target-local privilege check before the handler runs, so exploitation needs no account on the victim.
UI:N - Once the OCFS2/DLM domain is joined, exploitation is driven entirely by attacker-sent o2net messages and requires no victim user action such as mounting or opening a file.
S:U - The heap overflow and resulting kernel impact remain within the same kernel and OCFS2 cluster-node security authority and do not cross a guest-to-host or IOMMU boundary.
C:H - Unchecked namelen produces a heap out-of-bounds write of attacker-controlled bytes past the o2dlm_mle slab object and an out-of-bounds read of the source name buffer, which can disclose adjacent kernel memory.
I:H - dlm_init_mle() memcpy()s up to 255 attacker-controlled bytes into the 32-byte mname[] of an o2dlm_mle slab object, overflowing the object by about 215 bytes and enabling overwrite of adjacent heap objects and kernel control-flow hijacking.
A:H - The heap out-of-bounds write past the o2dlm_mle slab object can oops or panic the receiving node, fully denying availability.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - DLM_MIGRATE_REQUEST is received and dispatched by the ocfs2 o2net TCP cluster transport, so dlm_migrate_request_handler() is reached through network protocol messages from a peer node.
AC:L - A cluster peer can send a crafted DLM_MIGRATE_REQUEST with attacker-chosen namelen; dlm_init_mle() then memcpy()s that length into the 32-byte mname[] with no race or other condition outside the attacker's control.
PR:N - o2net gates peers by configured node IP, heartbeat, and the DLM domain key, with no user authentication or target-local privilege check before the handler runs, so exploitation needs no account on the victim.
UI:N - Once the OCFS2/DLM domain is joined, exploitation is driven entirely by attacker-sent o2net messages and requires no victim user action such as mounting or opening a file.
S:U - The heap overflow and resulting kernel impact remain within the same kernel and OCFS2 cluster-node security authority and do not cross a guest-to-host or IOMMU boundary.
C:H - Unchecked namelen produces a heap out-of-bounds write of attacker-controlled bytes past the o2dlm_mle slab object and an out-of-bounds read of the source name buffer, which can disclose adjacent kernel memory.
I:H - dlm_init_mle() memcpy()s up to 255 attacker-controlled bytes into the 32-byte mname[] of an o2dlm_mle slab object, overflowing the object by about 215 bytes and enabling overwrite of adjacent heap objects and kernel control-flow hijacking.
A:H - The heap out-of-bounds write past the o2dlm_mle slab object can oops or panic the receiving node, fully denying availability.
CVSS 3.1