From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80073145B11 for ; Wed, 13 May 2026 02:47:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778640467; cv=none; b=Ws4EERJaEjBYG2eRt0Zuu0hlSZ7gq9u1mhl9jIWnotnOEceZwuCQZOE/8wvg0gPnydI7Ar6WtjCuApSfUMyR08NwZJN+nUFE4hIw/9rs/uupNcGqzGSGQTUpQcTnd8qq7nc/Bsio/GhGHgT9/xD8jAj28Kc9C8LB12/JZS2DSBA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778640467; c=relaxed/simple; bh=6w63HbBOf5eBiZV5/hBEx/RiXkI44paJJ82Sf/J+13w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R4AAPGWrODI71aF/j9DjhP6gP4lZZggLE8L4JYXQC8ldvX6cm71hlvk/E4lN2q97uk0r1cVNhqXzWGEe9NeWYP3Kh7ys6PWmqtHzypf/pt4TwJgNgUgvjx4UOi7/KF09DvBgpHN2G9AAqlKhn2GbaWEgw7xCo4yOl//5MLbSXjg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Bh2m23aK; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Bh2m23aK" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-367cbac9c37so2842433a91.2 for ; Tue, 12 May 2026 19:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1778640466; x=1779245266; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=06gGqdUNMKvX/WJ+4BlOMkKZ5L7m8iKcXoUPE36yZHM=; b=Bh2m23aKOwQ4j2KJ1A47nThEKEiuWuWpIoYnz+wejmmqM+zFI7SC5deKknKBKFz114 0wuCC8b+sVHYYkLNCIdrXJLcYOWXoQuQHEIThfu6kcqDQrYDSa6iF8EuR1nDXXOGqohS bxOAIXZ1YULaEVK5LL2vProq8dPnwzSILuD/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778640466; x=1779245266; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=06gGqdUNMKvX/WJ+4BlOMkKZ5L7m8iKcXoUPE36yZHM=; b=gRB32C39kUS0VaVGMGCat1hbLgJiMcLSUapszRcfScYhwAiBwDGd7z5LUQFqfEXHms wHYf2fw11C3hshZQTQM8fYyaWv24SNeBWGRuzTQeGjI4eMeUPr8Zj9w27OlXgakYaxCO h8aEcIdZ1sFCCB+pZyy/F9Go7YeAT2w7VWGvMmsEWNXgyuJmbSO84JeRUGygJTxR8Guw 3CmHJeBNtX9vC0Wt9fZDWoaIkjOVuu9o87zIsQ5EUB73wNGCO21sOmrYZ6GgIiZlx0BW u0IghyzPoaLRi49ubdA1HMQPbYi6x0Ey7cmmjdKhvq7pVVJlLq09mFe7DDMdzhJyC9d0 2AFw== X-Forwarded-Encrypted: i=1; AFNElJ+0eITtiVlWOL8xGI14nnZQBh47PMm0two6VMwzgKgjg391/JO8FZgvLZuknE3GBzy8JsgLtSvVNdFHrMc=@vger.kernel.org X-Gm-Message-State: AOJu0YwiUVU7l0p2jWngPKQrhJX3MjIgYQMkNyJKge1StZ2lbDlPXhng RoX2zSAEIzjTmWHNHGDsNxpQZsMDf0uJi2cuVGe94HhkiawmhZYXstqGhgsmdQSMTQ== X-Gm-Gg: Acq92OEzg8zlnFl9Q6d7PAopJwDveW8FrsMpgBqb2gNhdLbAletqC+j36GIkyM2jnzP t1jIJt4Z7pblUPiztrX0reQ9g9lz42TnBqYJMd8/zVOLE+NYREdvf0A+op7oSCdC2Lp//tjrsdE paExEgnWNSAKatf1YBU0y0ZUR2D4oV7zDs8tpVvTDg3tHK7H1f93mRAGF5X/bpPUs//Kx6UHwfk QiBrr2f7YBvY2WA1l/EJFkREoEyO+MTCEoa5tysjMmnRLY352y1QitySp2WkX2MdzQOtSLL6Csg EUfIk4o7EVm3uysby+IT6esxTRw/oIW+4ACrVHvAhEJ8/uxhlsE8c/tJK9M7x4HgYSHEpNMhT5r uITjHjvIsGxXq3lMllg2C4aX0qtc8oCb681eSVeAaduiy3hziIEVVMPViTooFAqenmxtvymEnr9 TRpc2Wxv4wxXAgg3SxW/D2i808Hj4c8472Izd5/I0RBXOS1D0TQq4vT0eyJPhZL9tl6c0T3ytN5 A== X-Received: by 2002:a17:90b:4f92:b0:368:f179:ba07 with SMTP id 98e67ed59e1d1-368f3aa9f3cmr1629152a91.9.1778640465784; Tue, 12 May 2026 19:47:45 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:e541:a7ed:e8ee:843c]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-368b06d6b33sm1567998a91.10.2026.05.12.19.47.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 19:47:45 -0700 (PDT) Date: Wed, 13 May 2026 11:47:41 +0900 From: Sergey Senozhatsky To: Andrew Morton , Yosry Ahmed , Herbert Xu Cc: Kartik Nair , minchan@kernel.org, senozhatsky@chromium.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+8f77ff6144a73f0cf71b@syzkaller.appspotmail.com, Nhat Pham , Yosry Ahmed , Herbert Xu Subject: Re: [PATCH] zsmalloc: zero-initialize zspage memory to prevent KMSAN uninit reads Message-ID: References: <20260511213658.25273-1-contact.kartikn@gmail.com> <20260512144733.9132c83e392a109743e92f71@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260512144733.9132c83e392a109743e92f71@linux-foundation.org> 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? > > Fix this by passing __GFP_ZERO to alloc_zpdesc() in alloc_zspage() so > > all pages backing a zspage are zero-initialized at allocation time. > > > > Reported-by: syzbot+8f77ff6144a73f0cf71b@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=8f77ff6144a73f0cf71b > > Signed-off-by: Kartik Nair > > Thanks. > > > --- a/mm/zsmalloc.c > > +++ b/mm/zsmalloc.c > > @@ -951,7 +951,7 @@ static struct zspage *alloc_zspage(struct zs_pool *pool, > > for (i = 0; i < class->pages_per_zspage; i++) { > > struct zpdesc *zpdesc; > > > > - zpdesc = alloc_zpdesc(gfp, nid); > > + zpdesc = alloc_zpdesc(gfp | __GFP_ZERO, nid); > > if (!zpdesc) { > > while (--i >= 0) { > > zpdesc_dec_zone_page_state(zpdescs[i]); > > Decompressing uninitialized memory sounds rather bad, so I'll add a > cc:stable to this. [..] > I think the Fixes: target is 56e5a103a721 ("zsmalloc: prefer the the > original page's node for compressed data"). Can people please check > this when reviewing? If we need to pick a zsmalloc commit, then this probably can be related to zs_obj_read_sg_begin() API (which is used only by zswap at the moemnt), so probably the Fixes: tag be dc2e4982cb018 (zsmalloc: introduce SG-list based object read API).