PT-2026-90211 · Linux · Linux
CVE-2026-89495
·
Published
2026-09-11
·
Updated
2026-09-11
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux