Re: [PATCH 0/2] ocfs2/dlm: bound peer-controlled lengths in the o2dlm receive path

On Thu, 2 Jul 2026 13:56:00 +0800, Joseph Qi wrote:
> Ocfs2 is always deployed in trusted network, so how to trigger this
> issue in real environment?

Agreed on the precondition: there's no local trigger, and a random host off the
cluster can't reach this. The sender has to be a node the cluster's o2net layer
accepts, so it isn't remote-unauthenticated.

The real-environment trigger isn't a malicious admin. It's a single compromised
member: code execution on one node via any unrelated flaw, or a node wrongly
admitted to the interconnect. o2net admits senders by node configuration, not by
any secret -- so "trusted network" is the whole boundary. From that one foothold
you can corrupt the kernel heap of, or panic, every other node in the domain.
Node B's kernel integrity shouldn't depend on node A never being compromised.

> IMO, the patches are reasonable as a belt hardening against future bugs
> or operational accidents, but not overstate the risk by framing it as a
> security vulnerability.

The DLM already treats these wire fields as untrusted, so this isn't a belt
against a hypothetical. The lock-operation handlers reject an oversized name the
moment they read it:

  dlm_master_request_handler   fs/ocfs2/dlm/dlmmaster.c:1426
  dlm_create_lock_handler      fs/ocfs2/dlm/dlmlock.c:469
  dlm_convert_lock_handler     fs/ocfs2/dlm/dlmconvert.c:450
  dlm_unlock_lock_handler      fs/ocfs2/dlm/dlmunlock.c:416

same namelen > DLM_LOCKID_NAME_MAX test in all four. dlm_migrate_request_handler
and dlm_mig_lockres_handler take the identical u8 field into the identical
32-byte buffer and skip it. The patches just make them consistent with the rest
of the receive path. Here the sender's u8 length (up to 255) reaches the 32-byte
slab buffer with no bound, and the sender controls the copied bytes too. That's
a heap OOB write.

The framing is your call as maintainer, and the fix is identical either way. If
ocfs2's position is that a joined member is inside the trust boundary, I won't
argue the CVE -- but these two are attacker-length-and-content-controlled heap
OOB writes, which is why I didn't post them as robustness-only. Either way I'd
like the bound to land.

Thanks for the review,
Bryam