Cloudanix VulnDB

CVE-2026-89495

Critical · 9.8

CVSS

9.8

EPSS

0.7%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux clustered disk software can let one machine already in the cluster crash or damage the others, taking shared storage down until those systems are updated.

Exploitation
Remote Authenticated
Attacker needs
Other
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The OCFS2 o2dlm receive path trusts peer-supplied u8 length and count fields on DLM migrate and recovery messages. An oversized migrate namelen or lockres lockname_len is memcpy'd into fixed 32-byte slab objects (o2dlm_mle mname[] / o2dlm_lockname), producing a heap out-of-bounds write of up to roughly 215–223 attacker-controlled bytes. An inflated num_locks causes dlm_process_recovery_data() to walk past the kmalloc'd message copy, an out-of-bounds read that hits a BUG_ON and panics the receiving node. o2net authenticates only by DLM domain key, so any domain member can reach these handlers.

Why it matters to the business

A malicious or compromised cluster member can crash peer nodes or corrupt kernel heap on systems sharing OCFS2 storage, taking clustered filesystems offline and interrupting workloads that depend on that shared storage. Integrity of kernel memory on victim nodes is also at risk. The issue is not in CISA KEV, is not tied to ransomware, has no known exploit in the wild, and EPSS remains low and flat (~0.007 over 30 days), but impact is cluster-wide once a node is in the domain. Treat unpatched OCFS2/o2dlm hosts as an availability and integrity risk until kernels are updated.

How an attack unfolds

The attacker must already be a member of the OCFS2 DLM domain (compromised node, stolen domain key, or otherwise admitted peer); there is no unprivileged local trigger. From that foothold they send a malformed DLM_MIGRATE_REQUEST or migration/recovery lockres message over o2net with an unbounded name length or lock count. The receiving kernel copies or iterates past the fixed-size slab buffers, corrupting adjacent heap or panicking via BUG_ON. Conforming migrate/recovery traffic does not hit the bug. Public exploit maturity is none; named threat-actor use is not reported.

How to fix it

Install a Linux kernel that includes the ocfs2/dlm bounds checks: dlm_migrate_request_handler must reject oversized namelen before dlm_init_mle(), and dlm_mig_lockres_handler must validate lockname_len, num_locks, and that the message is large enough for the claimed entries before dlm_init_lockres()/dlm_process_recovery_data(). Use your distribution's kernel that maps this CVE, or upstream patches in the ocfs2/dlm series. Until then, admit only fully trusted nodes to the DLM domain, restrict o2net to the cluster interconnect, and do not join untrusted hosts. Legitimate migrate/recovery traffic is unchanged by the fix. Rebuild or replace any out-of-tree ocfs2/o2dlm modules so they match the patched kernel.

How to confirm the fix worked

Inventory nodes with OCFS2 and o2dlm (mounted ocfs2 filesystems, o2cb/o2dlm loaded, DLM domain membership). Confirm the running kernel changelog or distro CVE mapping includes the namelen/lockname_len/num_locks checks. After upgrade, verify cluster join, lock mastery, recovery, and inode/lock migration still succeed with normal traffic, and that oversized names are rejected in the patched handlers. Compare uname/kernel package version against the vendor advisory; hosts still on pre-fix kernels remain exposed.

Typical attack path

  1. Gain membership in the target OCFS2/o2dlm domain (compromise an existing node or obtain the DLM domain key)
  2. Reach peer o2net and send a malformed DLM migrate or recovery message with unbounded namelen, lockname_len, or num_locks
  3. Victim kernel performs an unchecked copy or walk into o2dlm slab objects
  4. Heap corruption and/or immediate kernel panic on the receiving node; cluster storage services on that node fail

How to detect it

This is a kernel memory-corruption/panic bug, not a userland implant, so look for crash evidence rather than malware files. Review dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore from OCFS2 nodes around unexplained reboots. Search oops traces for o2dlm migrate/recovery frames (dlm_migrate_request_handler, dlm_mig_lockres_handler, dlm_init_mle, dlm_init_lockres, dlm_process_recovery_data) and KASAN slab-out-of-bounds on o2dlm_mle or o2dlm_lockname caches, or BUG_ON during recovery-data walk. Correlate with o2net/DLM domain join from a peer that should not have been sending migrate/recovery traffic. Absence of these logs does not prove non-exploitation if kdump was off and the node simply rebooted. No public in-the-wild campaign IOCs are associated with this CVE.

  • dlm_migrate_request_handler
  • dlm_mig_lockres_handler
  • dlm_init_mle
  • dlm_init_lockres
  • dlm_process_recovery_data
  • o2dlm_mle
  • o2dlm_lockname
  • KASAN: slab-out-of-bounds
  • BUG_ON
  • ocfs2
  • o2dlm
  • o2net

What your security team should do

  • Patch OCFS2/o2dlm kernels first on production cluster nodes; do not wait for KEV listing given cluster-wide panic/corruption impact
  • Until patched, treat DLM domain membership as a trust boundary: no untrusted or weakly isolated hosts in the domain, o2net limited to the cluster network
  • Hunt kernel oops/panic/kdump on ocfs2 nodes for o2dlm migrate/recovery handler frames from the last 32+ days
  • Ensure kdump/vmcore and persistent kernel logs are enabled on cluster nodes so a future panic is attributable
  • Track distro kernel advisories for exact package versions; rebuild custom kernels with the ocfs2/dlm fixes
  • Reassess after patching that EPSS and KEV remain unused-in-the-wild; no extra emergency measures beyond cluster isolation are indicated by current exploitation data

The record

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.

Affected packages

Ecosystem Package Introduced Fixed