[syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    ea1013c15392 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d2e31a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b3903bdf68407a14
dashboard link: https://syzkaller.appspot.com/bug?extid=178fff6149127421c2cc
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/27172fba4316/disk-ea1013c1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ac8c65aa1d08/vmlinux-ea1013c1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/42241f684d1d/bzImage-ea1013c1.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+178fff6149127421c2cc@syzkaller.appspotmail.com

=====================================================
BUG: KMSAN: uninit-value in is_folio_zero_filled mm/page_io.c:188 [inline]
BUG: KMSAN: uninit-value in swap_writeout+0x468/0x1390 mm/page_io.c:263
 is_folio_zero_filled mm/page_io.c:188 [inline]
 swap_writeout+0x468/0x1390 mm/page_io.c:263
 shmem_writeout+0x1abb/0x1f60 mm/shmem.c:1662
 writeout mm/vmscan.c:649 [inline]
 pageout mm/vmscan.c:698 [inline]
 shrink_folio_list+0x5920/0x7fc0 mm/vmscan.c:1418
 evict_folios+0x999d/0xbf30 mm/vmscan.c:4711
 try_to_shrink_lruvec+0x12b6/0x17e0 mm/vmscan.c:4874
 lru_gen_shrink_lruvec mm/vmscan.c:5023 [inline]
 shrink_lruvec+0x46f/0x4f10 mm/vmscan.c:5784
 shrink_node_memcgs mm/vmscan.c:6020 [inline]
 shrink_node+0xf1e/0x51e0 mm/vmscan.c:6061
 shrink_zones mm/vmscan.c:6300 [inline]
 do_try_to_free_pages+0x849/0x26b0 mm/vmscan.c:6362
 try_to_free_mem_cgroup_pages+0x3ae/0x950 mm/vmscan.c:6690
 try_charge_memcg+0x80f/0x1c50 mm/memcontrol.c:2388
 obj_cgroup_charge_pages+0x2ed/0x600 mm/memcontrol.c:2823
 __memcg_kmem_charge_page+0x14a/0x4c0 mm/memcontrol.c:2867
 __alloc_frozen_pages_noprof+0x3ba/0xab0 mm/page_alloc.c:5227
 alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2486
 alloc_frozen_pages_noprof mm/mempolicy.c:2557 [inline]
 alloc_pages_noprof+0x102/0x280 mm/mempolicy.c:2577
 io_mem_alloc_compound io_uring/memmap.c:30 [inline]
 io_region_allocate_pages+0x164/0x900 io_uring/memmap.c:165
 io_create_region+0x6d0/0x830 io_uring/memmap.c:220
 io_allocate_scq_urings+0x1e3/0x8a0 io_uring/io_uring.c:3379
 io_uring_create+0x7b5/0x1040 io_uring/io_uring.c:3643
 io_uring_setup io_uring/io_uring.c:3718 [inline]
 __do_sys_io_uring_setup io_uring/io_uring.c:3752 [inline]
 __se_sys_io_uring_setup+0x3f0/0x410 io_uring/io_uring.c:3743
 __ia32_sys_io_uring_setup+0x76/0xb0 io_uring/io_uring.c:3743
 ia32_sys_call+0x2c57/0x4340 arch/x86/include/generated/asm/syscalls_32.h:426
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0x15a/0x330 arch/x86/entry/syscall_32.c:307
 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:332
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:370
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e

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
 __do_sys_symlinkat fs/namei.c:5562 [inline]
 __se_sys_symlinkat fs/namei.c:5559 [inline]
 __ia32_sys_symlinkat+0xf5/0x180 fs/namei.c:5559
 ia32_sys_call+0x385e/0x4340 arch/x86/include/generated/asm/syscalls_32.h:305
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0x15a/0x330 arch/x86/entry/syscall_32.c:307
 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:332
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:370
 entry_SYSENTER_compat_after_hwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 7862 Comm: syz.2.517 Tainted: G             L      syzkaller #0 PREEMPT(none) 
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[Barry Song]

>
> 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.

Clearing newly allocated folios in shmem_get_folio_gfp() would
fix the issue, but it may not be the proper solution. We will
need Hugh and Baolin’s guidance to recommend an appropriate fix.

>  __do_sys_symlinkat fs/namei.c:5562 [inline]
>  __se_sys_symlinkat fs/namei.c:5559 [inline]
>  __ia32_sys_symlinkat+0xf5/0x180 fs/namei.c:5559
>  ia32_sys_call+0x385e/0x4340 arch/x86/include/generated/asm/syscalls_32.h:305
>  do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
>  __do_fast_syscall_32+0x15a/0x330 arch/x86/entry/syscall_32.c:307
>  do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:332
>  do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:370
>  entry_SYSENTER_compat_after_hwframe+0x84/0x8e
>
> CPU: 0 UID: 0 PID: 7862 Comm: syz.2.517 Tainted: G             L      syzkaller #0 PREEMPT(none)
> Tainted: [L]=SOFTLOCKUP
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> =====================================================

Thanks
Barry

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[Pedro Falcato]

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.

-- 
Pedro

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[Barry Song]

On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato <pfalcato@suse.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

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[Baolin Wang]

On 2025/12/24 08:16, Barry Song wrote:
> On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato <pfalcato@suse.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.

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.

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[Barry Song]

On Wed, Dec 24, 2025 at 2:43 PM Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>
>
>
> On 2025/12/24 08:16, Barry Song wrote:
> > On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato <pfalcato@suse.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.
>
> 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.

Thanks, Baolin. Let me request a bot test first.

#syz test

diff --git a/mm/shmem.c b/mm/shmem.c
index ec6c01378e9d..835900a08f51 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);
+		folio_zero_range(folio, len, folio_size(folio) - len);
 		folio_mark_uptodate(folio);
 		folio_mark_dirty(folio);
 		folio_unlock(folio);
-- 
2.48.1

Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writeout

[syzbot]

> On Wed, Dec 24, 2025 at 2:43 PM Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2025/12/24 08:16, Barry Song wrote:
>> > On Wed, Dec 24, 2025 at 12:43 PM Pedro Falcato <pfalcato@suse.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.
>>
>> 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.
>
> Thanks, Baolin. Let me request a bot test first.
>
> #syz test

This crash does not have a reproducer. I cannot test it.

>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ec6c01378e9d..835900a08f51 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);
> +		folio_zero_range(folio, len, folio_size(folio) - len);
>  		folio_mark_uptodate(folio);
>  		folio_mark_dirty(folio);
>  		folio_unlock(folio);
> -- 
> 2.48.1