Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Sven Schnelle <svens@linux.ibm.com>
To:     Lorenzo Stoakes <lstoakes@gmail.com>
Cc:     "Liam R. Howlett" <Liam.Howlett@oracle.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        syzbot+a7c1ec5b1d71ceaa5186@syzkaller.appspotmail.com,
        stable@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH] mm/mempolicy: Fix use-after-free of VMA iterator
References: <20230410152205.2294819-1-Liam.Howlett@oracle.com>
        <yt9dildhke9l.fsf@linux.ibm.com>
        <20230427173247.s5rn6nujoxiatviu@revolver>
        <5066f333-5021-451d-abdd-07a027d98820@lucifer.local>
Date:   Mon, 01 May 2023 20:24:48 +0200
In-Reply-To: <5066f333-5021-451d-abdd-07a027d98820@lucifer.local> (Lorenzo
        Stoakes's message of "Sun, 30 Apr 2023 14:35:00 +0100")
Message-ID: <yt9da5yn7vv3.fsf@linux.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Content-Type: text/plain
MIME-Version: 1.0
Precedence: bulk

Lorenzo Stoakes <lstoakes@gmail.com> writes:

> On Thu, Apr 27, 2023 at 01:32:47PM -0400, Liam R. Howlett wrote:
>> * Sven Schnelle <svens@linux.ibm.com> [230427 02:53]:
>> > "Liam R. Howlett" <Liam.Howlett@oracle.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@syzkaller.appspotmail.com
>> > > Fixes: 66850be55e8e ("mm/mempolicy: use vma iterator & maple state instead of vma linked list")
>> > > Cc: <stable@vger.kernel.org>
>> > > Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.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.