Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler 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->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. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:31.370Z",
  "pubdate": "2026-09-11T20:19:31.370Z",
  "executiveSummary": "The Linux kernel OCFS2 Distributed Lock Manager (DLM) contains a critical input validation vulnerability within the dlm_mig_lockres_handler function.\nThis vulnerability involves an improper validation of peer-supplied data during lock resource migration, leading to both out-of-bounds reads and writes.\nThe flaw stems from trusting fields such as num_locks and lockname_len without verifying their alignment with the actual received payload length or the bounds of the destination data structures.\nThe impact includes system instability, potential kernel-level memory corruption, and a subsequent system panic triggered by a BUG_ON condition.\nThe vulnerability is exploitable by any node participating in the OCFS2 cluster, meaning an attacker with control over a single compromised node can force memory corruption on peer nodes.\nThis represents a high risk to cluster integrity, as successful exploitation enables arbitrary memory access via heap overflows, potentially leading to privilege escalation or remote code execution within the kernel context.\nImmediate remediation requires applying kernel patches that enforce strict size bounds on the migratable_lock structures and their associated lock names before any processing occurs.",
  "technicalDetails": "The vulnerability resides in the dlm_mig_lockres_handler function, which processes incoming DLM_MIG_LOCKRES messages. When a node receives these messages, it allocates memory using kmalloc(data_len) to store the peer-supplied dlm_migratable_lockres structure. However, the handler fails to perform sufficient boundary checks on critical metadata fields, specifically num_locks and lockname_len, provided by the sender.\nThe root cause is a failure to sanitize these fields against the actual size of the received buffer. The lack of validation creates two primary attack vectors: First, an out-of-bounds read occurs in dlm_process_recovery_data when it iterates through the migratable_lock array (mres->ml[0..num_locks)). If num_locks is inflated beyond the actual payload length, the kernel accesses memory outside the heap allocation, resulting in a BUG_ON triggered panic.\nSecond, a heap-based out-of-bounds write occurs in dlm_init_lockres. The function attempts to copy lockname_len bytes into a fixed-size 32-byte slab object intended for o2dlm_lockname. By providing a crafted lockname_len, an attacker can overflow this heap object, overwriting adjacent kernel memory structures.\nThe attack flow proceeds as follows: An attacker node sends a malicious DLM_MIG_LOCKRES packet to a target node. The packet contains an inflated num_locks field and an oversized lockname_len field. Upon receipt, the target node's dlm_mig_lockres_handler allocates the buffer and fails to validate the constraints. The subsequent processing function, dlm_init_lockres, performs the memory copy operation using the attacker-controlled length, causing the overflow into adjacent kernel memory. Simultaneously, dlm_process_recovery_data attempts to read past the buffer boundaries, resulting in an immediate denial-of-service condition via a kernel BUG_ON.\nThis vulnerability is reachable by any node in the OCFS2 domain, implying that compromise of a single node allows for lateral exploitation against all other nodes in the cluster. Because the DLM operates at the kernel level, this memory corruption provides a powerful primitive for attackers to overwrite critical kernel pointers or data structures, bypassing standard user-mode security controls and potentially executing arbitrary code with kernel-level privileges."
}