Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:31.493Z",
  "pubdate": "2026-09-11T20:19:31.493Z",
  "executiveSummary": "The OCFS2 (Oracle Cluster File System 2) Distributed Lock Manager (o2dlm) is vulnerable to multiple heap-based buffer overflows due to improper validation of length fields in incoming network messages.\nA malicious or compromised node within an OCFS2 cluster can transmit malformed DLM_MIGRATE_REQUEST or recovery packets to trigger memory corruption on peer nodes.\nThe vulnerability type encompasses both heap out-of-bounds writes and out-of-bounds reads, leading to potential arbitrary code execution, kernel memory corruption, or system panics.\nThis issue affects the Linux kernel OCFS2 implementation. Exploitation requires the attacker to be a member of the DLM domain, as the o2net protocol only authenticates peers via the DLM domain key.\nSuccessful exploitation allows an attacker to overwrite adjacent slab objects in kernel memory with attacker-controlled data, bypassing standard safety checks.\nThe impact is critical, as it allows a single compromised node to destabilize or take control of the entire cluster by inducing kernel panics or executing malicious code in the context of the kernel.",
  "technicalDetails": "The root cause of the vulnerability lies in the o2dlm receive handlers, specifically dlm_migrate_request_handler and dlm_mig_lockres_handler, which accept length and count fields directly from the network wire without bounds checking.\nIn dlm_migrate_request_handler, the migrate->namelen field is passed unsanitized to dlm_init_mle(). This function subsequently uses memcpy() to copy up to 255 bytes of data into a fixed 32-byte mname[] buffer residing within an o2dlm_mle slab object. This results in a heap out-of-bounds write of approximately 215 bytes, allowing for the corruption of adjacent slab memory.\nSimilarly, in dlm_mig_lockres_handler, the mres->lockname_len field is not validated before being used in a memcpy() operation to fill a 32-byte o2dlm_lockname slab object. This leads to an additional heap out-of-bounds write of approximately 223 bytes.\nFurthermore, dlm_mig_lockres_handler fails to validate the mres->num_locks field against the actual size of the received network message. When dlm_process_recovery_data() attempts to process these locks, it traverses the mres->ml[] array based on the untrusted num_locks value. If this value exceeds the actual data length, the loop performs an out-of-bounds read, eventually hitting a kernel BUG_ON, which causes a denial of service (system panic).\nThe attack flow requires the adversary to be an established member of the OCFS2 cluster. Once authenticated to the cluster, the attacker crafts packets with malicious length fields exceeding the defined capacity of the target slab structures. By targeting the heap, an attacker can influence the kernel memory layout to overwrite function pointers, object metadata, or other critical kernel data structures present in the slab allocator.\nThese vulnerabilities were confirmed via KASAN and memory corruption analysis. Because the OCFS2 migration and recovery handlers neglected to implement the same bounds checking present in other o2dlm receive handlers, the kernel remained exposed to peer-controlled memory corruption for an extended period."
}