Re: [PATCH] dlm: fix RCOM_LOOKUP length underflow

[Alexander Aring]

Hi,

On Fri, Sep 11, 2026 at 2:54 AM Aohan Mei <ljp1205831794@xxxxxxxxx> wrote:
>
> From: Aohan Mei <henrymei@xxxxxxxxxxx>
>
> receive_rcom_lookup() derives the resource name length from the
> peer-supplied 16-bit h_length header field:
>
>     int len = le16_to_cpu(rc_in->rc_header.h_length) -
>               sizeof(struct dlm_rcom);
>
> The 3.1 receive path only bounds h_length to the range
> [sizeof(struct dlm_header), DLM_MAX_SOCKET_BUFSIZE] in
> dlm_validate_incoming_buffer(), and the RCOM case in
> dlm_midcomms_receive_buffer_3_1() performs no further length check
> despite its "length already checked" comment.  A peer can therefore
> send an RCOM_LOOKUP message whose h_length is smaller than
> sizeof(struct dlm_rcom) (48).  The subtraction is evaluated in size_t
> arithmetic and wraps, and the result is assigned to an int as a
> negative value.
>
> Both consumers of that length only guard the upper bound
> (len > DLM_RESNAME_MAXLEN), which a negative len passes as a signed
> comparison:
>
> - with rc_id == 0xffffffff, len reaches dlm_dump_rsb_name() ->
>   dlm_search_rsb_tree(), where memcpy() converts it to a huge size_t
>   and overflows the on-stack 64-byte key buffer;

This case is already covered in dlm/next. [0]

> - otherwise len reaches dlm_master_lookup() -> _dlm_master_lookup(),
>   where jhash() converts it to a huge u32 and reads out of bounds.
>

This case is partially covered but lacks a check for negative values.
Can you send a patch to change it to unsigned int? [1]

- Alex

[0] https://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git/tree/fs/dlm/lock.c?h=next#n632
[1] https://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git/tree/fs/dlm/lock.c?h=next#n1273