[PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Joseph Qi]

commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
not catch negative values. While the input 'len' can be negative and a
negative int passed to memcpy() is implicitly converted to a large
size_t, causing a stack buffer overflow on the key[] array.

Fix this by changing the 'len' parameter type from int to unsigned int.
This ensures negative values from callers are implicitly converted to
large unsigned values that are caught by the existing
len > DLM_RESNAME_MAXLEN check.

Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
---
 fs/dlm/lock.c | 6 ++++--
 fs/dlm/lock.h | 4 ++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index c381e1028446..373abdb4354a 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -622,12 +622,14 @@ static int get_rsb_struct(struct dlm_ls *ls, const void *name, int len,
 	return 0;
 }
 
-int dlm_search_rsb_tree(struct rhashtable *rhash, const void *name, int len,
-			struct dlm_rsb **r_ret)
+int dlm_search_rsb_tree(struct rhashtable *rhash, const void *name,
+			unsigned int len, struct dlm_rsb **r_ret)
 {
 	char key[DLM_RESNAME_MAXLEN] = {};
+
 	if (len > DLM_RESNAME_MAXLEN)
 		return -EINVAL;
+
 	memcpy(key, name, len);
 	*r_ret = rhashtable_lookup_fast(rhash, &key, dlm_rhash_rsb_params);
 	if (*r_ret)
diff --git a/fs/dlm/lock.h b/fs/dlm/lock.h
index b23d7b854ed4..c75975937331 100644
--- a/fs/dlm/lock.h
+++ b/fs/dlm/lock.h
@@ -31,8 +31,8 @@ void resume_scan_timer(struct dlm_ls *ls);
 int dlm_master_lookup(struct dlm_ls *ls, int from_nodeid, const char *name,
 		      int len, unsigned int flags, int *r_nodeid, int *result);
 
-int dlm_search_rsb_tree(struct rhashtable *rhash, const void *name, int len,
-			struct dlm_rsb **r_ret);
+int dlm_search_rsb_tree(struct rhashtable *rhash, const void *name,
+			unsigned int len, struct dlm_rsb **r_ret);
 
 void dlm_recover_purge(struct dlm_ls *ls, const struct list_head *root_list);
 void dlm_purge_mstcpy_locks(struct dlm_rsb *r);
-- 
2.39.3

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>
> commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does

check with checkpath, it reports an error regarding how this commit
reference is done.

- Alex

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> >
> > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
>
> check with checkpath, it reports an error regarding how this commit
> reference is done.
>

This also addresses CVE-2026-43125 [0].

- Alex

[0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > Hi,
> >
> > On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> > >
> > > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
> >
> > check with checkpath, it reports an error regarding how this commit
> > reference is done.
> >
>
> This also addresses CVE-2026-43125 [0].
>
> - Alex
>
> [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/

cc the right folks cve@kernel.org as described in the kernel documentation.

There is another patch required for CVE-2026-43125 [0].

Joseph I think for v3 you should cc also cve@kernel.org and mention
this in your commit msg.

Thanks.

- Alex

[0] https://lore.kernel.org/gfs2/20260517020315.1064253-1-joseph.qi@linux.alibaba.com/

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Greg KH]

On Tue, May 26, 2026 at 09:58:32AM -0400, Alexander Aring wrote:
> Hi,
> 
> On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > Hi,
> >
> > On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> > > >
> > > > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
> > >
> > > check with checkpath, it reports an error regarding how this commit
> > > reference is done.
> > >
> >
> > This also addresses CVE-2026-43125 [0].
> >
> > - Alex
> >
> > [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/
> 
> cc the right folks cve@kernel.org as described in the kernel documentation.

For what?

> There is another patch required for CVE-2026-43125 [0].
> 
> Joseph I think for v3 you should cc also cve@kernel.org and mention
> this in your commit msg.

Why doesn't this deserve a different CVE id when it lands in the public
trees?

thanks,

greg k-h

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Joseph Qi]

On 5/26/26 9:58 PM, Alexander Aring wrote:
> Hi,
> 
> On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
>>
>> Hi,
>>
>> On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>>>>
>>>> commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
>>>
>>> check with checkpath, it reports an error regarding how this commit
>>> reference is done.
>>>
>>
>> This also addresses CVE-2026-43125 [0].
>>
>> - Alex
>>
>> [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/
> 
> cc the right folks cve@kernel.org as described in the kernel documentation.
> 
> There is another patch required for CVE-2026-43125 [0].
> 
> Joseph I think for v3 you should cc also cve@kernel.org and mention
> this in your commit msg.
> 

This is indeed found when I backport this CVE into our tree.
But I think it is a different case so I just send to upstream first.

Thanks,
Joseph

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Tue, May 26, 2026 at 9:01 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>
>
>
> On 5/26/26 9:58 PM, Alexander Aring wrote:
> > Hi,
> >
> > On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> >>>>
> >>>> commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
> >>>
> >>> check with checkpath, it reports an error regarding how this commit
> >>> reference is done.
> >>>
> >>
> >> This also addresses CVE-2026-43125 [0].
> >>
> >> - Alex
> >>
> >> [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/
> >
> > cc the right folks cve@kernel.org as described in the kernel documentation.
> >
> > There is another patch required for CVE-2026-43125 [0].
> >
> > Joseph I think for v3 you should cc also cve@kernel.org and mention
> > this in your commit msg.
> >
>
> This is indeed found when I backport this CVE into our tree.
> But I think it is a different case so I just send to upstream first.
>

In my opinion the first patch did not fix the vulnerability described
in CVE-2026-43125, but with your additional changes it does. This
means it is the same case.

A different case would be if -EINVAL is returned and we cannot recover
from it (e.g., deadlock or something, but probably not a CVE). That is
a different case, DLM is mostly currently running in a local
environment, which is why I am not very worried about it. I have it on
my list to check. I wrote once a scapy module [0] to create and feed
DLM messages to discover such things; it might be a starting point.

- Alex

[0] https://github.com/alexaring/scapy/commits/dlm/

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Tue, May 26, 2026 at 12:09 PM Greg KH <gregkh@kernel.org> wrote:
>
> On Tue, May 26, 2026 at 09:58:32AM -0400, Alexander Aring wrote:
> > Hi,
> >
> > On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> > > > >
> > > > > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
> > > >
> > > > check with checkpath, it reports an error regarding how this commit
> > > > reference is done.
> > > >
> > >
> > > This also addresses CVE-2026-43125 [0].
> > >
> > > - Alex
> > >
> > > [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/
> >
> > cc the right folks cve@kernel.org as described in the kernel documentation.
>
> For what?
>

because

"If the CVE assignment team misses a specific fix that any user feels
should have a CVE assigned to it, please email them at
<cve@kernel.org> and the team there will work with you on it." [0]

The initial fix did not resolve CVE-2026-43125, there are additional
changes are required.

> > There is another patch required for CVE-2026-43125 [0].
> >
> > Joseph I think for v3 you should cc also cve@kernel.org and mention
> > this in your commit msg.
>
> Why doesn't this deserve a different CVE id when it lands in the public
> trees?
>

because the vulnerability described in CVE-2026-43125 is the same, I'm
also not sure I cc "cve@kernel.org" that the team there will work with
me on it as the kernel doc told me. :)

thanks.

- Alex

[0] https://docs.kernel.org/process/cve.html

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Greg KH]

On Fri, May 29, 2026 at 09:24:59AM -0400, Alexander Aring wrote:
> Hi,
> 
> On Tue, May 26, 2026 at 12:09 PM Greg KH <gregkh@kernel.org> wrote:
> >
> > On Tue, May 26, 2026 at 09:58:32AM -0400, Alexander Aring wrote:
> > > Hi,
> > >
> > > On Mon, May 25, 2026 at 1:39 PM Alexander Aring <aahringo@redhat.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> > > > > >
> > > > > > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
> > > > >
> > > > > check with checkpath, it reports an error regarding how this commit
> > > > > reference is done.
> > > > >
> > > >
> > > > This also addresses CVE-2026-43125 [0].
> > > >
> > > > - Alex
> > > >
> > > > [0] https://lore.kernel.org/linux-cve-announce/2026050619-CVE-2026-43125-c9f9@gregkh/
> > >
> > > cc the right folks cve@kernel.org as described in the kernel documentation.
> >
> > For what?
> >
> 
> because
> 
> "If the CVE assignment team misses a specific fix that any user feels
> should have a CVE assigned to it, please email them at
> <cve@kernel.org> and the team there will work with you on it." [0]
> 
> The initial fix did not resolve CVE-2026-43125, there are additional
> changes are required.

That CVE describes the specific issue that that patch fixes.  If there
are additional issues that this patch does not resolve, then it deserves
a new CVE for the new fix, OR you should add the new sha1 to the old CVE
entry.

Where is the new fix?

thanks,

greg k-h

Re: [PATCH v2] dlm: fix buffer overflow from negative len in dlm_search_rsb_tree

[Alexander Aring]

Hi,

On Mon, May 25, 2026 at 10:27 AM Alexander Aring <aahringo@redhat.com> wrote:
>
> Hi,
>
> On Sat, May 16, 2026 at 10:03 PM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> >
> > commit 080e5563f878 only checks for len > DLM_RESNAME_MAXLEN, which does
>
> check with checkpath, it reports an error regarding how this commit
> reference is done.

I fixed your commit message for this patch; checkpatch requires a very
specific commit reference style here.
It's "commit 080e5563f878c ("dlm: validate length in dlm_search_rsb_tree")".

- Alex