Re: [PATCH] zsmalloc: zero-initialize zspage memory to prevent KMSAN uninit reads

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (26/05/13 13:43), Herbert Xu wrote:
> On Wed, May 13, 2026 at 11:47:41AM +0900, Sergey Senozhatsky wrote:
> > Adding Yosry and Herbert,
> > 
> > On (26/05/12 14:47), Andrew Morton wrote:
> > > > Pages allocated via alloc_zpdesc() use alloc_pages_node() without
> > > > __GFP_ZERO, leaving physical memory uninitialized. When a compressed
> > > > object spans two physical pages in a zspage, zs_obj_read_sg_begin()
> > > > sets up a scatterlist pointing directly at the raw second page. If the
> > > > second page was freshly allocated and never written beyond the object
> > > > boundary, KMSAN detects reads of uninitialized memory downstream in
> > > > the decompressor (e.g. sw842_decompress reading the CRC trailer).
> > 
> > I don't get this.  How can sw842_decompress() read more bytes than
> > it's told to decompress.  We first compress and store the object,
> > before we load and decompress, reading past the known compressed
> > object size (which we pass to decompress function) should not happen.
> > Yosry, Herbert, any ideas?
> 
> It sounds like a bug in 842.  I'll look into it.

Thanks!  The report doesn't have a reproducer, that is always alarming,
a big red flag.  Might be entirely unrelated to 842/zsmalloc/zswap.