linux-kernel - Re: [PATCH] mm/slab_common: fix slab_caches list corruption after kmem_cache

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZPvPmU9vBXQoFBm4@x1-fbsd.aquini.net>
Date:   Fri, 8 Sep 2023 21:51:21 -0400
From:   Rafael Aquini <aquini@...hat.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Waiman Long <longman@...hat.com>,
        Rafael Aquini <raquini@...hat.com>, stable@...r.kernel.org
Subject: Re: [PATCH] mm/slab_common: fix slab_caches list corruption after
 kmem_cache_destroy()

On Sat, Sep 09, 2023 at 02:16:00AM +0100, Matthew Wilcox wrote:
> On Fri, Sep 08, 2023 at 07:06:49PM -0400, Rafael Aquini wrote:
> > This patch fixes this issue by properly checking shutdown_cache()'s
> > return value before taking the kmem_cache_release() branch.
> 
> Is this the right way to fix this problem?  If the module destroys the
> slab cache, it's not going to be possible to free any of the objects
> still allocated from the cache.  I feel that we should treat this as
> implicitly freeing all the objects that were allocated from the cache
> rather than saying the cache is still busy.
>

Leaving the cache with the unfreeable slabs "alone" is how it was historically 
done, and we have to fix this corner case opened by 0495e337b703 this way to 
address the corruption on stable releases without changing their established 
and expected behavior.

I think your proposal for a different behavior upon cache destruction is
something we should discuss for future releases, but it is orthogonal to
this required follow-up fix.