Re: [PATCH v2] kasan, mm: fix crash with HW_TAGS and DEBUG_PAGEALLOC

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 6 Mar 2021 00:54:32 +0100 Andrey Konovalov <andreyknvl@google.com> wrote:

> On Sat, Mar 6, 2021 at 12:50 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Sat,  6 Mar 2021 00:36:33 +0100 Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> > > Currently, kasan_free_nondeferred_pages()->kasan_free_pages() is called
> > > after debug_pagealloc_unmap_pages(). This causes a crash when
> > > debug_pagealloc is enabled, as HW_TAGS KASAN can't set tags on an
> > > unmapped page.
> > >
> > > This patch puts kasan_free_nondeferred_pages() before
> > > debug_pagealloc_unmap_pages() and arch_free_page(), which can also make
> > > the page unavailable.
> > >
> > > ...
> > >
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1304,6 +1304,12 @@ static __always_inline bool free_pages_prepare(struct page *page,
> > >
> > >       kernel_poison_pages(page, 1 << order);
> > >
> > > +     /*
> > > +      * With hardware tag-based KASAN, memory tags must be set before the
> > > +      * page becomes unavailable via debug_pagealloc or arch_free_page.
> > > +      */
> > > +     kasan_free_nondeferred_pages(page, order, fpi_flags);
> > > +
> > >       /*
> > >        * arch_free_page() can make the page's contents inaccessible.  s390
> > >        * does this.  So nothing which can access the page's contents should
> > > @@ -1313,8 +1319,6 @@ static __always_inline bool free_pages_prepare(struct page *page,
> > >
> > >       debug_pagealloc_unmap_pages(page, 1 << order);
> > >
> > > -     kasan_free_nondeferred_pages(page, order, fpi_flags);
> > > -
> > >       return true;
> > >  }
> >
> > kasan_free_nondeferred_pages() has only two args in current mainline.
> 
> Ah, yes, forgot to mention: this goes on top of:
> 
> kasan: initialize shadow to TAG_INVALID for SW_TAGS
> mm, kasan: don't poison boot memory with tag-based modes

This patch (kasan, mm: fix crash with HW_TAGS and DEBUG_PAGEALLOC) is
cc:stable, so it should come head of the other two lower priority
patches.

> >
> > I fixed that in the obvious manner...
> 
> Thanks!
> 
> If you changed this patch, you'll also need to change the other one though.


Yup.