[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+178fff...@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 syzk...@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

[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

[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

[Barry Song]

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

[Baolin Wang]

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

[Barry Song]

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

[syzbot]

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