linux-kernel - Re: WARNING bisected (was Re: [PATCH v7 08/10] mm: rework non-root kmem

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: <20191121205520.GA5815@localhost.localdomain>
Date:   Thu, 21 Nov 2019 20:55:27 +0000
From:   Roman Gushchin <guro@...com>
To:     Rik van Riel <riel@...com>
CC:     Christian Borntraeger <borntraeger@...ibm.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        Kernel Team <Kernel-team@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "longman@...hat.com" <longman@...hat.com>,
        "shakeelb@...gle.com" <shakeelb@...gle.com>,
        "vdavydov.dev@...il.com" <vdavydov.dev@...il.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: WARNING bisected (was Re: [PATCH v7 08/10] mm: rework non-root
 kmem_cache lifecycle management)

On Thu, Nov 21, 2019 at 12:43:01PM -0800, Rik van Riel wrote:
> On Thu, 2019-11-21 at 13:45 -0500, Roman Gushchin wrote:
> > On Thu, Nov 21, 2019 at 05:59:54PM +0100, Christian Borntraeger
> > wrote:
> > > 
> > > 
> > > Yes, rmmod has to be called directly after the guest shutdown to
> > > see the issue.
> > > See my 2nd mail.
> > 
> > I see. Do you know, which kmem_cache it is? If not, can you, please,
> > figure it out?
> > 
> > I tried to reproduce the issue, but wasn't successful so far. So I
> > wonder
> > what can make your case special.
> 
> I do not know either, but have a guess.
> 
> My guess would be that either the slab object or the
> slab page is RCU freed, and the kmem_cache destruction
> is called before that RCU callback has completed.
> 

I've a reproducer, but it requires SLAB_TYPESAFE_BY_RCU to panic.
The only question is if it's the same or different issues.
As soon as I'll have a fix, I'll post it here to test.

Thanks!