> -----Original Message----- > From: Johannes Weiner <hannes@xxxxxxxxxxx> > Sent: Wednesday, November 13, 2024 9:12 PM > To: Sridhar, Kanchana P <kanchana.p.sridhar@xxxxxxxxx> > Cc: Nhat Pham <nphamcs@xxxxxxxxx>; Yosry Ahmed > <yosryahmed@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux- > mm@xxxxxxxxx; chengming.zhou@xxxxxxxxx; usamaarif642@xxxxxxxxx; > ryan.roberts@xxxxxxx; Huang, Ying <ying.huang@xxxxxxxxx>; > 21cnbao@xxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; Feghali, Wajdi K > <wajdi.k.feghali@xxxxxxxxx>; Gopal, Vinodh <vinodh.gopal@xxxxxxxxx> > Subject: Re: [PATCH v1] mm: zswap: Fix a potential memory leak in > zswap_decompress(). > > On Thu, Nov 14, 2024 at 01:56:16AM +0000, Sridhar, Kanchana P wrote: > > So my question was, can we prevent the migration to a different cpu > > by relinquishing the mutex lock after this conditional > > Holding the mutex doesn't prevent preemption/migration. Sure, however, is this also applicable to holding the mutex of a per-cpu structure obtained via raw_cpu_ptr()? Would holding the mutex prevent the acomp_ctx of the cpu prior to the migration (in the UAF scenario you described) from being deleted? If holding the per-cpu acomp_ctx's mutex isn't sufficient to prevent the UAF, I agree, we might need a way to prevent the acomp_ctx from being deleted, e.g. with refcounts as you've suggested, or to not use the acomp_ctx at all for the check, instead use a boolean. Thanks, Kanchana
