linux-kernel - Re: [PATCH v3] mm: memcg/slab: fix memory leak at 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] [day] [month] [year] [list]

Message-ID: <20200716193925.GA13387@carbon.dhcp.thefacebook.com>
Date:   Thu, 16 Jul 2020 12:39:25 -0700
From:   Roman Gushchin <guro@...com>
To:     Vlastimil Babka <vbabka@...e.cz>
CC:     Muchun Song <songmuchun@...edance.com>, <cl@...ux.com>,
        <penberg@...nel.org>, <rientjes@...gle.com>,
        <iamjoonsoo.kim@....com>, <akpm@...ux-foundation.org>,
        <shakeelb@...gle.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] mm: memcg/slab: fix memory leak at non-root
 kmem_cache destroy

On Thu, Jul 16, 2020 at 07:21:42PM +0200, Vlastimil Babka wrote:
> On 7/16/20 6:51 PM, Muchun Song wrote:
> > If the kmem_cache refcount is greater than one, we should not
> > mark the root kmem_cache as dying. If we mark the root kmem_cache
> > dying incorrectly, the non-root kmem_cache can never be destroyed.
> > It resulted in memory leak when memcg was destroyed. We can use the
> > following steps to reproduce.
> > 
> >   1) Use kmem_cache_create() to create a new kmem_cache named A.
> >   2) Coincidentally, the kmem_cache A is an alias for kmem_cache B,
> >      so the refcount of B is just increased.
> >   3) Use kmem_cache_destroy() to destroy the kmem_cache A, just
> >      decrease the B's refcount but mark the B as dying.
> >   4) Create a new memory cgroup and alloc memory from the kmem_cache
> >      B. It leads to create a non-root kmem_cache for allocating memory.
> >   5) When destroy the memory cgroup created in the step 4), the
> >      non-root kmem_cache can never be destroyed.
> > 
> > If we repeat steps 4) and 5), this will cause a lot of memory leak.
> > So only when refcount reach zero, we mark the root kmem_cache as dying.
> > 
> > Fixes: 92ee383f6daa ("mm: fix race between kmem_cache destroy, create and deactivate")
> > Signed-off-by: Muchun Song <songmuchun@...edance.com>
> > Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
> > Acked-by: Roman Gushchin <guro@...com>
> 
> Cc: <stable@...r.kernel.org>
> 
> And it will need to go before the series that starts with
> mm-memcg-factor-out-memcg-and-lruvec-level-changes-out-of-__mod_lruvec_state.patch
> 
> most likely causing some collisions there to be fixed up...

Collisions should be simple, as all this code with corresponding problems is
removed by the series. So in theory we can even skip applying to 5.9,
not sure if it's a good idea though.

Thanks!