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 also rejecting len <= 0.

Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
---
 fs/dlm/lock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index c381e1028446..124f68c8e653 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -626,8 +626,10 @@ int dlm_search_rsb_tree(struct rhashtable *rhash, const void *name, int len,
 			struct dlm_rsb **r_ret)
 {
 	char key[DLM_RESNAME_MAXLEN] = {};
-	if (len > DLM_RESNAME_MAXLEN)
+
+	if (len <= 0 || len > DLM_RESNAME_MAXLEN)
 		return -EINVAL;
+
 	memcpy(key, name, len);
 	*r_ret = rhashtable_lookup_fast(rhash, &key, dlm_rhash_rsb_params);
 	if (*r_ret)
-- 
2.39.3

Hi,

On Fri, May 15, 2026 at 3:39 AM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>
> 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 also rejecting len <= 0.

or change the parameter to unsigned?

- Alex

On 5/15/26 9:30 PM, Alexander Aring wrote:
> Hi,
> 
> On Fri, May 15, 2026 at 3:39 AM Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>>
>> 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 also rejecting len <= 0.
> 
> or change the parameter to unsigned?
> 

Yes, it would be fine. I'll work on it and send v2 later.

Thanks,
Joseph