Re: [mm/page_alloc or mm/vmscan or mm/zswap] use-after-free in obj_malloc()

[Yosry Ahmed <yosryahmed@google.com>]

On Thu, Feb 22, 2024 at 8:58 PM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> On (24/02/23 13:56), Sergey Senozhatsky wrote:
> > On (24/02/22 20:50), Yosry Ahmed wrote:
> > > On Thu, Feb 22, 2024 at 8:48 PM Sergey Senozhatsky
> > > <senozhatsky@chromium.org> wrote:
> > > >
> > > > On (24/02/22 18:27), Yosry Ahmed wrote:
> > > > > I also don't see any recent changes in mm/zsmalloc.c that modify this
> > > > > code, so maybe it wasn't introduce in 6.7. I will defer to Minchan and
> > > > > Sergey, I don't think zswap is an active actor in this bug report.
> > > >
> > > > Yeah. [1] are the only recent zsmalloc patches I can recall, and those
> > > > patches touch zsmalloc locking (zspages migration/compaction).
> > > >
> > > > https://lore.kernel.org/lkml/20240219-b4-szmalloc-migrate-v1-0-34cd49c6545b@bytedance.com/
> > >
> > > These are not in 6.8.0-rc5 anyway, right?
> >
> > I see them in next-20240223, which seems to be 6.8-rc6 (according to
>                                                    ^ -rc5
>
> But they look more or less correct to me, so I'm not blaming those
> patches.  We should be protected by pool->look.  Bisection would help
> us a lot, I think.

Andrew picked up those patches in mm-unstable, which is included in
linux-next at some point IIUC, but the patches there don't all end up
in the next rc unless I am misunderstanding something here. These
patches should be headed to v6.9 AFAICT.

Actually, if I am not mistaken the patches were sent *after* v.6.8-rc5
was out, and it's not common for non-fixes to make it into rc releases
anyway, right?