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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACT4Y+bjP-3L8E2+3tZ3F37W-hjnz5Zhb5t+fcaAu1NYferr3A@mail.gmail.com>
Date: Mon, 5 Jan 2026 10:12:53 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: Barry Song <21cnbao@...il.com>, pfalcato@...e.de, akpm@...ux-foundation.org, 
	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, 24 Dec 2025 at 02:43, Baolin Wang <baolin.wang@...ux.alibaba.com> wrote:
>
>
> On 2025/12/24 08:16, Barry Song wrote:
> > 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.
>
> Thanks for CCing me.
>
> >>>
> >>> 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.


> This would be an unfortunate way to fix it.  The vast majority of
> symlinks are short, and we'll never access past the \0 in normal
> operation, so we'll be dirtying a lot of cachelines essentially to (1)
> shut up an automated tool and (2) optimise a corner case.

Won't the uninit data end up in a swap file if it's not 0's? If yes,
isn't leaking crypto keys to a swap file a problem?


> Thanks Pedro and Barry. I remember Hugh raised a similar issue before
> (See [1], but I did not investigate further:(). I agree with Hugh's
> point that the uninitialized parts should be zeroed before going the
> outside world.
>
> [1]
> https://lore.kernel.org/all/02a21a55-8fe3-a9eb-f54b-051d75ae8335@google.com/
>
> > 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);
>
> That looks reasonable to me, though I prefer to use the more readable
> helper: folio_zero_range(). Barry, could you send out a formal patch？
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@...glegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/9bbc1962-5f6f-4e3c-a672-d80565aa5157%40linux.alibaba.com.