linux-kernel - Re: [PATCH] mm/mempolicy: Fix use-after-free of VMA iterator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <yt9da5yn7vv3.fsf@linux.ibm.com>
Date:   Mon, 01 May 2023 20:24:48 +0200
From:   Sven Schnelle <svens@...ux.ibm.com>
To:     Lorenzo Stoakes <lstoakes@...il.com>
Cc:     "Liam R. Howlett" <Liam.Howlett@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        syzbot+a7c1ec5b1d71ceaa5186@...kaller.appspotmail.com,
        stable@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [PATCH] mm/mempolicy: Fix use-after-free of VMA iterator

Lorenzo Stoakes <lstoakes@...il.com> writes:

> On Thu, Apr 27, 2023 at 01:32:47PM -0400, Liam R. Howlett wrote:
>> * Sven Schnelle <svens@...ux.ibm.com> [230427 02:53]:
>> > "Liam R. Howlett" <Liam.Howlett@...cle.com> writes:
>> >
>> > > set_mempolicy_home_node() iterates over a list of VMAs and calls
>> > > mbind_range() on each VMA, which also iterates over the singular list of
>> > > the VMA passed in and potentially splits the VMA.  Since the VMA
>> > > iterator is not passed through, set_mempolicy_home_node() may now point
>> > > to a stale node in the VMA tree.  This can result in a UAF as reported
>> > > by syzbot.
>> > >
>> > > Avoid the stale maple tree node by passing the VMA iterator through to
>> > > the underlying call to split_vma().
>> > >
>> > > mbind_range() is also overly complicated, since there are two calling
>> > > functions and one already handles iterating over the VMAs.  Simplify
>> > > mbind_range() to only handle merging and splitting of the VMAs.
>> > >
>> > > Align the new loop in do_mbind() and existing loop in
>> > > set_mempolicy_home_node() to use the reduced mbind_range() function.
>> > > This allows for a single location of the range calculation and avoids
>> > > constantly looking up the previous VMA (since this is a loop over the
>> > > VMAs).
>> > >
>> > > Link: https://lore.kernel.org/linux-mm/000000000000c93feb05f87e24ad@google.com/
>> > > Reported-and-tested-by: syzbot+a7c1ec5b1d71ceaa5186@...kaller.appspotmail.com
>> > > Fixes: 66850be55e8e ("mm/mempolicy: use vma iterator & maple state instead of vma linked list")
>> > > Cc: <stable@...r.kernel.org>
>> > > Signed-off-by: Liam R. Howlett <Liam.Howlett@...cle.com>
>> > > ---
>> >
>> > This breaks the vma02 testcase from ltp on s390:
>> >
>> >  ~ # ./vma02
>> > vma02       0  TINFO  :  pid = 617 addr = 0x3ff8f673000
>> > vma02       0  TINFO  :  start = 0x3ff8f673000, end = 0x3ff8f674000
>> > vma02       0  TINFO  :  start = 0x3ff8f674000, end = 0x3ff8f675000
>> > vma02       0  TINFO  :  start = 0x3ff8f675000, end = 0x3ff8f676000
>> > vma02       1  TFAIL  :  vma02.c:144: >1 unmerged VMAs.
>> > Any thoughts?
>>
>> No thoughts that I should share.
>>
>> I will have to boot my s390 (vm) and have a look.
>>
>> Thanks for letting me know.
>>
>> Regards,
>> Liam
>
> I tracked down what this (almost certainly) was + added fix in [1] as it
> popped up as a 6.2.y stable bug. It doesn't seem arch-specific so you can
> put that s390 down :)
>
> [1]:https://lore.kernel.org/all/db42467a692d78c654ec5c1953329401bd8a9c34.1682859234.git.lstoakes@gmail.com/

Thanks, just tested, and it solves the issue for me.