| 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
| ||
|
Message-ID: <684ffb0a-2cc0-4ea3-b5f7-b0518ed2e83d@gmail.com> Date: Fri, 11 Oct 2024 16:28:55 +0100 From: Usama Arif <usamaarif642@...il.com> To: Andrew Morton <akpm@...ux-foundation.org>, syzbot <syzbot+febb2473441bfb8fb380@...kaller.appspotmail.com>, Hugh Dickins <hughd@...gle.com> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, syzkaller-bugs@...glegroups.com, Nhat Pham <nphamcs@...il.com>, Johannes Weiner <hannes@...xchg.org>, Yosry Ahmed <yosryahmed@...gle.com>, Chengming Zhou <chengming.zhou@...ux.dev> Subject: Re: [syzbot] [mm?] KMSAN: uninit-value in swap_writepage On 10/10/2024 22:23, Andrew Morton wrote: > On Thu, 10 Oct 2024 01:44:27 -0700 syzbot <syzbot+febb2473441bfb8fb380@...kaller.appspotmail.com> wrote: > >> Hello, >> >> syzbot found the following issue on: >> >> HEAD commit: fc20a3e57247 Merge tag 'for-linus-6.12a-rc2-tag' of git://.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=11cdfd27980000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=d302f14701986aa0 >> dashboard link: https://syzkaller.appspot.com/bug?extid=febb2473441bfb8fb380 >> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 >> >> Unfortunately, I don't have any reproducer for this issue yet. >> >> Downloadable assets: >> disk image: https://storage.googleapis.com/syzbot-assets/5b4b9aca7b75/disk-fc20a3e5.raw.xz >> vmlinux: https://storage.googleapis.com/syzbot-assets/b22e17636ec0/vmlinux-fc20a3e5.xz >> kernel image: https://storage.googleapis.com/syzbot-assets/5266e625be99/bzImage-fc20a3e5.xz >> >> IMPORTANT: if you fix the issue, please add the following tag to the commit: >> Reported-by: syzbot+febb2473441bfb8fb380@...kaller.appspotmail.com > > Thanks. I'm guessing that shmem symlinks aren't initializing the whole > page (folio) and that has tripped up Usama's "store zero pages to be > swapped out in a bitmap" feature - it's checking the uninitialized part > of the page for zeroness. > This is a very similar bug to the one in https://lore.kernel.org/all/000000000000d0f165061a6754c3@google.com/ (Thanks Nhat for pointing this out!) As Hugh mentioned in that thread, its likely not a bug in (z)swap. Its just working with the folio that was given to it, and it should probably be initialized before swap_writepage is called. I havent worked on shmem code before, but will try to have a look. Hugh mentioned in the other thread that shmem can keep uninitialized data pages around, but should be zeroing what's still uninitialized before it can reach the outside world. Maybeshmem_symlink gets a folio that wasnt initialized? Thanks, Usama > >> ===================================================== >> BUG: KMSAN: uninit-value in is_folio_zero_filled mm/page_io.c:189 [inline] >> BUG: KMSAN: uninit-value in swap_writepage+0x536/0x12b0 mm/page_io.c:259 >> is_folio_zero_filled mm/page_io.c:189 [inline] >> swap_writepage+0x536/0x12b0 mm/page_io.c:259 >> shmem_writepage+0x2117/0x2450 mm/shmem.c:1567 >> pageout mm/vmscan.c:688 [inline] >> shrink_folio_list+0x5e78/0x7dd0 mm/vmscan.c:1366 >> evict_folios+0x9813/0xbaf0 mm/vmscan.c:4583 >> try_to_shrink_lruvec+0x13a3/0x1750 mm/vmscan.c:4778 >> shrink_one+0x646/0xd20 mm/vmscan.c:4816 >> shrink_many mm/vmscan.c:4879 [inline] >> lru_gen_shrink_node mm/vmscan.c:4957 [inline] >> shrink_node+0x451a/0x50f0 mm/vmscan.c:5937 >> kswapd_shrink_node mm/vmscan.c:6765 [inline] >> balance_pgdat mm/vmscan.c:6957 [inline] >> kswapd+0x25e2/0x42f0 mm/vmscan.c:7226 >> kthread+0x3e2/0x540 kernel/kthread.c:389 >> ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:147 >> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 >> >> Uninit was created at: >> __alloc_pages_noprof+0x9d6/0xe70 mm/page_alloc.c:4756 >> alloc_pages_mpol_noprof+0x299/0x990 mm/mempolicy.c:2265 >> folio_alloc_mpol_noprof+0x55/0x180 mm/mempolicy.c:2283 >> shmem_alloc_folio mm/shmem.c:1774 [inline] >> shmem_alloc_and_add_folio+0xc33/0x1c30 mm/shmem.c:1813 >> shmem_get_folio_gfp+0xacd/0x1f30 mm/shmem.c:2335 >> shmem_get_folio mm/shmem.c:2441 [inline] >> shmem_symlink+0x528/0xa20 mm/shmem.c:3834 >> vfs_symlink+0x1ed/0x460 fs/namei.c:4615 >> do_symlinkat+0x257/0x8a0 fs/namei.c:4641 >> __do_sys_symlink fs/namei.c:4662 [inline] >> __se_sys_symlink fs/namei.c:4660 [inline] >> __x64_sys_symlink+0xe0/0x140 fs/namei.c:4660 >> x64_sys_call+0x30e8/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:89 >> do_syscall_x64 arch/x86/entry/common.c:52 [inline] >> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 >> entry_SYSCALL_64_after_hwframe+0x77/0x7f >> >> CPU: 1 UID: 0 PID: 80 Comm: kswapd0 Tainted: G W 6.12.0-rc1-syzkaller-00330-gfc20a3e57247 #0 >> Tainted: [W]=WARN >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 >> ===================================================== >> >> >> --- >> 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@...glegroups.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
Powered by blists - more mailing lists