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

Hi,

On Tue, May 26, 2026 at 9:01=E2=80=AFPM Joseph Qi <[email protected].=
com> wrote:
>
>
>
> On 5/26/26 9:58 PM, Alexander Aring wrote:
> > Hi,
> >
> > On Mon, May 25, 2026 at 1:39=E2=80=AFPM Alexander Aring <aahringo@redha=
t.com> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, May 25, 2026 at 10:27=E2=80=AFAM Alexander Aring <aahringo@red=
hat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sat, May 16, 2026 at 10:03=E2=80=AFPM Joseph Qi <[email protected]=
libaba.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-431=
25-c9f9@gregkh/
> >
> > cc the right folks [email protected] as described in the kernel documentat=
ion.
> >
> > There is another patch required for CVE-2026-43125 [0].
> >
> > Joseph I think for v3 you should cc also [email protected] 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/