linux-kernel - Re: [syzbot] [mm?] KMSAN: uninit-value in swap

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251224001617.45293-1-21cnbao@gmail.com>
Date: Wed, 24 Dec 2025 13:16:16 +1300
From: Barry Song <21cnbao@...il.com>
To: pfalcato@...e.de
Cc: 21cnbao@...il.com,
	akpm@...ux-foundation.org,
	baolin.wang@...ux.alibaba.com,
	bhe@...hat.com,
	chrisl@...nel.org,
	hughd@...gle.com,
	kasong@...cent.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	nphamcs@...il.com,
	shikemeng@...weicloud.com,
	syzbot+178fff6149127421c2cc@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato <pfalcato@...e.de> wrote:
>
> On Wed, Dec 24, 2025 at 11:46:44AM +1300, Barry Song wrote:
> > >
> > > Uninit was created at:
> > >  __alloc_frozen_pages_noprof+0x421/0xab0 mm/page_alloc.c:5233
> > >  alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2486
> > >  folio_alloc_mpol_noprof+0x56/0x1d0 mm/mempolicy.c:2505
> > >  shmem_alloc_folio mm/shmem.c:1890 [inline]
> > >  shmem_alloc_and_add_folio+0xc56/0x1bd0 mm/shmem.c:1932
> > >  shmem_get_folio_gfp+0xad3/0x1fc0 mm/shmem.c:2556
> > >  shmem_get_folio mm/shmem.c:2662 [inline]
> > >  shmem_symlink+0x562/0xad0 mm/shmem.c:4129
> > >  vfs_symlink+0x42f/0x4c0 fs/namei.c:5514
> > >  do_symlinkat+0x2ae/0xbb0 fs/namei.c:5541
> >
> > +Hugh and Baolin.
> >
> > This happens in the shmem symlink path, where newly allocated
> > folios are not cleared for some reason. As a result,
> > is_folio_zero_filled() ends up reading uninitialized data.
> >
>
> I'm not Hugh nor Baolin, but I would guess that letting
> is_folio_zero_filled() skip/disable KMSAN would also work. Since all we want
> is to skip writeout if the folio is zero, whether it is incidentally zero, or not,
> does not really matter, I think.

Hi Pedro, thanks! You’re always welcome to chime in.

You are probably right. However, I still prefer the remaining
data to be zeroed, as it may be more compression-friendly.

Random data could potentially lead to larger compressed output,
whereas a large area of zeros would likely result in much smaller
compressed data.

Not quite sure if the below can fix the issue:

diff --git a/mm/shmem.c b/mm/shmem.c
index ec6c01378e9d..0ca2d4bffdb4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -4131,6 +4131,7 @@ static int shmem_symlink(struct mnt_idmap *idmap, struct inode *dir,
 			goto out_remove_offset;
 		inode->i_op = &shmem_symlink_inode_operations;
 		memcpy(folio_address(folio), symname, len);
+		memset(folio_address(folio) + len, 0, folio_size(folio) - len);
 		folio_mark_uptodate(folio);
 		folio_mark_dirty(folio);
 		folio_unlock(folio);

>
> --
> Pedro

Thanks
Barry