Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <000000000000fe575905b3cff92c@google.com> <bf31020f4e50b303fd0dd3dfda0e50de79ed25db.camel@redhat.com>
 <CAAeHK+yLgDYOS35sWT8=4_d-gZKU_B10D9ZEBPZDC1P6MO2D6Q@mail.gmail.com> <CAA5enKY8mBicpc7kZKKLG5LeVFhVJtRQ73MYVFM0Az2bbiGv8g@mail.gmail.com>
In-Reply-To: <CAA5enKY8mBicpc7kZKKLG5LeVFhVJtRQ73MYVFM0Az2bbiGv8g@mail.gmail.com>
From:   Andrey Konovalov <andreyknvl@google.com>
Date:   Wed, 11 Nov 2020 20:44:09 +0100
Message-ID: <CAAeHK+x4tWTY0ZuR6LHhm071bOnvZcfa=A-KLpSfUTkaxZHieA@mail.gmail.com>
Subject: Re: linux-next boot error: BUG: unable to handle kernel NULL pointer
 dereference in mempool_init_node
To:     Lorenzo Stoakes <lstoakes@gmail.com>
Cc:     Qian Cai <cai@redhat.com>,
        syzbot <syzbot+2d6f3dad1a42d86a5801@syzkaller.appspotmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        Linux-Next Mailing List <linux-next@vger.kernel.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Alexander Potapenko <glider@google.com>,
        Marco Elver <elver@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Nov 11, 2020 at 8:27 PM Lorenzo Stoakes <lstoakes@gmail.com> wrote:
>
> On Wed, 11 Nov 2020 at 17:44, Andrey Konovalov <andreyknvl@google.com> wrote:
> > I'll try to reproduce this and figure out the issue. Thanks for letting us know!
>
> I hope you don't mind me diving in here, I was taking a look just now
> and managed to reproduce this locally - I bisected the issue to
> 105397399 ("kasan: simplify kasan_poison_kfree").
>
> If I stick a simple check in as below it fixes the issue, so I'm
> guessing something is violating the assumptions in 105397399?
>
>
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 7a94cebc0324..16163159a017 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -387,6 +387,11 @@ void __kasan_slab_free_mempool(void *ptr, unsigned long ip)
>         struct page *page;
>
>         page = virt_to_head_page(ptr);
> +
> +       if (!PageSlab(page)) {
> +               return;
> +       }
> +
>         ____kasan_slab_free(page->slab_cache, ptr, ip, false);
>  }

Ah, by the looks of it, ceph's init_caches() functions asks for
kmalloc-backed mempool, but at the same time provides a size that
doesn't fit into any kmalloc cache, and kmalloc falls back onto
page_alloc. Hard to say whether this is an issue in ceph, but I guess
we'll have to make KASAN fool proof either way and keep the PageSlab()
check in kasan_slab_free_mempool().

Thank you for debugging this, Lorenzo. I'll fix this in v10.