mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: hexlabsecurity@proton.me, Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	Kurt Hackel <kurt.hackel@oracle.com>,
	Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>
Subject: Re: [PATCH 2/2] ocfs2: validate lengths in dlm_mig_lockres_handler
Date: Thu, 2 Jul 2026 19:05:15 +0800	[thread overview]
Message-ID: <c0498d59-fb5a-4f33-a989-5b23e38e3bd4@linux.alibaba.com> (raw)
In-Reply-To: <20260629-b4-disp-94fb6521-v1-2-6953bcc0421f@proton.me>



On 6/29/26 1:01 PM, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
> 
> A node receiving a DLM_MIG_LOCKRES message trusts several fields of the
> peer-supplied dlm_migratable_lockres without validation.  num_locks and
> lockname_len are bounded only on the sending side, and the message is
> never checked to actually carry num_locks migratable_lock entries.  As a
> result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the
> kmalloc(data_len) copy of the message (an out-of-bounds read that ends in
> a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the
> fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write).
> Both are reachable by any node in the domain.
> 
> Validate these fields right after dlm_grab(), before anything uses them --
> including the not-joined error path, which already prints mres->lockname
> with the unbounded lockname_len as a %.*s precision.  Reject the message
> unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <=
> DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the
> payload is large enough to hold the claimed locks.  Conforming recovery
> and migration messages are unaffected.
> 
> Fixes: 6714d8e86bf4 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>

Looks fine.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>

> ---
>  fs/ocfs2/dlm/dlmrecovery.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/fs/ocfs2/dlm/dlmrecovery.c b/fs/ocfs2/dlm/dlmrecovery.c
> index 128872bd945d..14d4c7c3eebd 100644
> --- a/fs/ocfs2/dlm/dlmrecovery.c
> +++ b/fs/ocfs2/dlm/dlmrecovery.c
> @@ -1357,6 +1357,15 @@ int dlm_mig_lockres_handler(struct o2net_msg *msg, u32 len, void *data,
>  	if (!dlm_grab(dlm))
>  		return -EINVAL;
>  
> +	if (mres->lockname_len > DLM_LOCKID_NAME_MAX ||
> +	    mres->num_locks > DLM_MAX_MIGRATABLE_LOCKS ||
> +	    be16_to_cpu(msg->data_len) < struct_size(mres, ml, mres->num_locks)) {
> +		mlog(ML_ERROR, "%s: invalid lockres migration message from %u\n",
> +		     dlm->name, mres->master);
> +		dlm_put(dlm);
> +		return -EINVAL;
> +	}
> +
>  	if (!dlm_joined(dlm)) {
>  		mlog(ML_ERROR, "Domain %s not joined! "
>  			  "lockres %.*s, master %u\n",
> 


  reply	other threads:[~2026-07-02 11:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29  5:01 [PATCH 0/2] ocfs2/dlm: bound peer-controlled lengths in the o2dlm receive path Bryam Vargas via B4 Relay
2026-06-29  5:01 ` [PATCH 1/2] ocfs2: bound namelen in dlm_migrate_request_handler Bryam Vargas via B4 Relay
2026-07-02 11:03   ` Joseph Qi
2026-06-29  5:01 ` [PATCH 2/2] ocfs2: validate lengths in dlm_mig_lockres_handler Bryam Vargas via B4 Relay
2026-07-02 11:05   ` Joseph Qi [this message]
2026-07-02  5:56 ` [PATCH 0/2] ocfs2/dlm: bound peer-controlled lengths in the o2dlm receive path Joseph Qi
2026-07-02  9:27   ` Bryam Vargas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0498d59-fb5a-4f33-a989-5b23e38e3bd4@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=hexlabsecurity@proton.me \
    --cc=jlbec@evilplan.org \
    --cc=kurt.hackel@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®