Re: [PATCH] tmpfs: zero unused folio tail for long symlinks

[Yousef Alhouseen]

I only observed the KMSAN uninitialized-read report and did not
establish user-visible corruption or disclosure. I agree that does not
justify stable backporting by itself.

Andrew, please drop the Cc: stable tag if the patch is carried.

Thank you for the review and for the pointer to Barry's earlier patch.

Thanks,
Yousef

On Mon, 29 Jun 2026 11:27:47 +0800, Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
> CC Barry.
>
> On 6/28/26 8:43 AM, Yousef Alhouseen wrote:
> > shmem_symlink() marks the entire folio uptodate after copying only the
> > NUL-terminated link target. The remainder of the freshly allocated folio
> > is left uninitialized.
> >
> > Reclaim may pass the whole folio to a swap compressor. KMSAN observed
> > sw842_compress() computing a checksum over the uninitialized tail. If
> > the folio is written to a swap device, those bytes can also leave the
> > kernel.
> >
> > Zero the remainder of the folio before marking it uptodate and dirty.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Reported-by: syzbot+bf5586280a66e9ccdfa9@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=bf5586280a66e9ccdfa9
> > Cc: stable@xxxxxxxxxxxxxxx
>
> Do we need CC stable? Have you observed any actual impact?
>
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@xxxxxxxxx>
> > ---
> > mm/shmem.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/shmem.c b/mm/shmem.c
> > index b51f83c970bb..b06c1ae2f50c 100644
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -4057,6 +4057,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);
> > + folio_zero_range(folio, len, folio_size(folio) - len);
> > folio_mark_uptodate(folio);
> > folio_mark_dirty(folio);
> > folio_unlock(folio);
>
> Thanks. Barry sent the same fix before[1] (though I forgot why it didn't
> get merged). I think this is a reasonable fix. So:
>
> Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
>
> [1] https://lore.kernel.org/lkml/20251224020424.52976-1-21cnbao@xxxxxxxxx/