linux-kernel - Re: linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init

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]

Date:   Wed, 11 Nov 2020 20:44:09 +0100
From:   Andrey Konovalov <andreyknvl@...gle.com>
To:     Lorenzo Stoakes <lstoakes@...il.com>
Cc:     Qian Cai <cai@...hat.com>,
        syzbot <syzbot+2d6f3dad1a42d86a5801@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Marco Elver <elver@...gle.com>
Subject: Re: linux-next boot error: BUG: unable to handle kernel NULL pointer
 dereference in mempool_init_node

On Wed, Nov 11, 2020 at 8:27 PM Lorenzo Stoakes <lstoakes@...il.com> wrote:
>
> On Wed, 11 Nov 2020 at 17:44, Andrey Konovalov <andreyknvl@...gle.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.