linux-kernel - Re: [PATCH] userfaultfd: fix remap event with MREMAP

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEXW_YR2=g5Sh1uFCoLKDSxswyeJieOP8uxMrf4ievePdkgbSg@mail.gmail.com>
Date:   Wed, 6 May 2020 20:55:55 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Brian Geffon <bgeffon@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Sonny Rao <sonnyrao@...gle.com>,
        Minchan Kim <minchan@...nel.org>,
        "Kirill A . Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH] userfaultfd: fix remap event with MREMAP_DONTUNMAP.

Hi Brian,

On Wed, May 6, 2020 at 1:32 PM Brian Geffon <bgeffon@...gle.com> wrote:
>
> It hasn't landed in a stable kernel yet, 5.7 is rc4 so I don't think
> it needs to cc stable, right?

I think the criteria is, if it has been merged into Linus's tree in a
kernel release, then CC'ing stable means any future stable releases of
the kernel will have the patch applied to the stable tree. The fix
patch itself will need to be merged into Linus tree at a future date
before being applied to the stable tree. But at least CC'ing stable
means it is tracked my stable bots and they'll do the right. This is
my understanding.

If the patch you are fixing was applied for v5.7 merge window, then I
don't think you need to CC stable.

> Andrew, I'd be happy to mail a new patch if necessary, otherwise here
> is the fixes:
>
> Fixes: e346b38 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")

I'd also avoid top-posting and send inline replies:
https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
https://lkml.org/lkml/2019/12/4/267

Thanks!

 - Joel


>
> Brian
>
>
> On Wed, May 6, 2020 at 10:28 AM Joel Fernandes <joel@...lfernandes.org> wrote:
> >
> > On Wed, May 6, 2020 at 1:22 PM Brian Geffon <bgeffon@...gle.com> wrote:
> > >
> > > A user is not required to set a new address when using
> > > MREMAP_DONTUNMAP as it can be used without MREMAP_FIXED.
> > > When doing so the remap event will use new_addr which may not
> > > have been set and we didn't propagate it back other then
> > > in the return value of remap_to.
> > >
> > > Because ret is always the new address it's probably more
> > > correct to use it rather than new_addr on the remap_event_complete
> > > call, and it resolves this bug.
> > >
> >
> > Does it need Fixes: tag, and CC to stable? Going into a stable kernel
> > will mean the stable kernel merges into ChromeOS also gets it.
> >
> > thanks,
> >
> >  - Joel
> >
> > > Signed-off-by: Brian Geffon <bgeffon@...gle.com>
> > > ---
> > >  mm/mremap.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/mm/mremap.c b/mm/mremap.c
> > > index c881abeba0bf..6aa6ea605068 100644
> > > --- a/mm/mremap.c
> > > +++ b/mm/mremap.c
> > > @@ -794,7 +794,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> > >         if (locked && new_len > old_len)
> > >                 mm_populate(new_addr + old_len, new_len - old_len);
> > >         userfaultfd_unmap_complete(mm, &uf_unmap_early);
> > > -       mremap_userfaultfd_complete(&uf, addr, new_addr, old_len);
> > > +       mremap_userfaultfd_complete(&uf, addr, ret, old_len);
> > >         userfaultfd_unmap_complete(mm, &uf_unmap);
> > >         return ret;
> > >  }
> > > --
> > > 2.26.2.526.g744177e7f7-goog
> > >