CVE-2026-89494

What it actually does

A receiving OCFS2/O2DLM node trusts peer-supplied DLM_MIG_LOCKRES fields (num_locks and lockname_len) without checking that the payload actually contains the claimed lock entries or that the lock name fits the fixed 32-byte o2dlm_lockname object. Processing can walk past the kmalloc'd message copy (out-of-bounds read culminating in a BUG_ON kernel panic in dlm_process_recovery_data) or memcpy an unbounded lockname_len into a 32-byte slab object in dlm_init_lockres (heap out-of-bounds write). Either outcome is reachable from any node in the DLM domain and can crash the kernel or corrupt kernel heap memory.

Why it matters to the business

Clustered Linux hosts using OCFS2 can be knocked offline or have kernel memory corrupted by a malicious or already-compromised peer, causing clustered filesystem unavailability, node fencing or reboot storms, and potential full host compromise. Impact is highest for shared-disk clusters (databases, HA file services, VM datastores). The issue is rated critical (CVSS 9.8) but is not in CISA KEV, has no known in-the-wild exploitation, and a low, flat EPSS (~0.007 over 30 days). It was published about a month ago, so patch windows should already be in flight; unpatched cluster interconnects remain a high-severity availability and integrity risk.

How an attack unfolds

An attacker who can participate in the O2DLM domain (a joined cluster node or an adversary able to inject DLM traffic on the cluster interconnect) sends a DLM_MIG_LOCKRES recovery/migration message whose num_locks and/or lockname_len exceed what the on-wire payload and the 32-byte lock-name object can hold. The receiver copies the message and, before the upstream validation fix, uses those fields in dlm_process_recovery_data and dlm_init_lockres (including the not-joined error path that prints the unbounded name). The result is a kernel oops/panic or a heap overflow of the o2dlm_lockname slab object, enabling denial of service and, with a follow-on memory-corruption primitive, possible kernel code execution on the victim node. Conforming recovery and migration traffic is unaffected; only malformed messages trigger the bug. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix that validates lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS, and that the message payload is large enough for the claimed locks, immediately after dlm_grab() (including the not-joined error path). Install the patched kernel from your distribution and reboot cluster nodes in a rolling, quorum-safe manner. If a vendor kernel is not yet available, restrict DLM/OCFS2 interconnects to known-good cluster members only (isolated network, strict host firewall/iptables/nftables, and node-join authentication) and avoid adding untrusted nodes to the domain. There are no per-package version pins in the supplied data; follow distro kernel advisories for the exact build that includes the ocfs2 dlm_mig_lockres_handler validation.

How to confirm the fix worked

Confirm running kernels include the ocfs2 change that rejects DLM_MIG_LOCKRES messages with lockname_len > DLM_LOCKID_NAME_MAX, num_locks > DLM_MAX_MIGRATABLE_LOCKS, or a payload too small for the claimed locks. Inventory nodes with OCFS2 mounted or o2dlm/o2cb in use (lsmod, mounted ocfs2 volumes, cluster stack packages). After patching and reboot, verify the new kernel release/changelog mentions the dlm_mig_lockres_handler validation, that the cluster reforms cleanly, and that normal lock recovery/migration still succeeds. Unpatched exposure is any live OCFS2 domain member still running a kernel without that check.

Typical attack path

1. Gain the ability to send O2DLM messages as a domain peer (compromised cluster node or attacker on the cluster interconnect).
2. Emit a DLM_MIG_LOCKRES message with untrusted num_locks and/or lockname_len that do not match the actual payload or the 32-byte lock-name bound.
3. Victim node accepts the message after dlm_grab() and uses the fields without length or payload-size checks.
4. Out-of-bounds read in recovery processing panics the kernel via BUG_ON, or unbounded copy overflows the o2dlm_lockname heap object.
5. Attacker achieves node crash/cluster disruption or attempts to turn heap corruption into further kernel compromise.

How to detect it

This is a kernel-memory bug with no public exploit maturity and no associated threat actors, so look for crash artifacts rather than a known payload. Review kernel logs (journalctl -k, /var/log/kern.log, dmesg, kdump/vmcore, pstore) on OCFS2 nodes around recovery or node-join events for oops, BUG_ON, or paging-request panics in dlm_process_recovery_data, dlm_init_lockres, or dlm_mig_lockres_handler. Correlate sudden node fencing, heartbeat timeouts, or cluster reformation with those traces. The unpatched not-joined error path can print an unbounded lock name; oversized or garbage lock names in DLM logs are suspicious. Capture vmcores for any ocfs2/dlm panic and inspect whether the faulting access is past the migratable lockres allocation or the 32-byte lock-name object. Network telemetry on the cluster interconnect showing unexpected DLM_MIG_LOCKRES-sized bursts from a peer immediately before a panic is a supporting indicator, not proof of exploit.

• dlm_process_recovery_data
• dlm_mig_lockres_handler
• dlm_init_lockres
• DLM_MIG_LOCKRES
• o2dlm_lockname
• kernel BUG at fs/ocfs2/dlm/
• BUG: unable to handle kernel paging request
• Call Trace: dlm_process_recovery_data
• Call Trace: dlm_init_lockres
• ocfs2_dlm
• o2dlm

What your security team should do

• Prioritize kernel updates on all OCFS2/O2DLM cluster members; schedule rolling reboots that preserve quorum.
• Until patched, lock down the cluster interconnect so only authenticated, expected nodes can send DLM traffic.
• Hunt historical kernel oops/panic logs for o2dlm/ocfs2 recovery paths; treat unexplained node fences during recovery as potentially related.
• Ensure cluster-join and heartbeat networks are not reachable from untrusted networks or multi-tenant segments.
• Track distro kernel advisories for this ocfs2 fix; EPSS is low and KEV is false, but CVSS 9.8 and cluster blast radius still justify prompt patching.