* KMSAN: uninit-value in mpol_rebind_mm @ 2018-12-31 7:51 syzbot 2019-01-03 8:36 ` Vlastimil Babka 0 siblings, 1 reply; 9+ messages in thread From: syzbot @ 2018-12-31 7:51 UTC (permalink / raw) To: aarcange, akpm, glider, kirill.shutemov, linux-kernel, linux-mm, linux, mhocko, rientjes, syzkaller-bugs, vbabka, xieyisheng1, zhongjiang Hello, syzbot found the following crash on: HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. git tree: kmsan console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 compiler: clang version 8.0.0 (trunk 349734) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com ================================================================== BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 CPU: 1 PID: 17420 Comm: syz-executor4 Not tainted 4.20.0-rc7+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:295 mpol_rebind_policy mm/mempolicy.c:353 [inline] mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 update_tasks_nodemask+0x608/0xca0 kernel/cgroup/cpuset.c:1120 update_nodemasks_hier kernel/cgroup/cpuset.c:1185 [inline] update_nodemask kernel/cgroup/cpuset.c:1253 [inline] cpuset_write_resmask+0x2a98/0x34b0 kernel/cgroup/cpuset.c:1728 cgroup_file_write+0x44a/0x8e0 kernel/cgroup/cgroup.c:3473 kernfs_fop_write+0x558/0x840 fs/kernfs/file.c:316 __vfs_write+0x1f4/0xb70 fs/read_write.c:485 __kernel_write+0x1fb/0x590 fs/read_write.c:506 write_pipe_buf+0x1c0/0x270 fs/splice.c:797 splice_from_pipe_feed fs/splice.c:503 [inline] __splice_from_pipe+0x48c/0xf10 fs/splice.c:627 splice_from_pipe fs/splice.c:662 [inline] default_file_splice_write+0x1ee/0x3c0 fs/splice.c:809 do_splice_from fs/splice.c:851 [inline] direct_splice_actor+0x19e/0x200 fs/splice.c:1023 splice_direct_to_actor+0x852/0x1140 fs/splice.c:978 do_splice_direct+0x342/0x580 fs/splice.c:1066 do_sendfile+0x108f/0x1de0 fs/read_write.c:1439 __do_sys_sendfile64 fs/read_write.c:1494 [inline] __se_sys_sendfile64+0x189/0x360 fs/read_write.c:1486 __x64_sys_sendfile64+0x56/0x70 fs/read_write.c:1486 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x4579b9 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f132b74cc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00000000004579b9 RDX: 0000000020000080 RSI: 0000000000000005 RDI: 0000000000000004 RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 00007f132b74d6d4 R13: 00000000004c471e R14: 00000000004d7d10 R15: 00000000ffffffff Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_save_stack mm/kmsan/kmsan.c:219 [inline] kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:439 kmsan_memcpy_memmove_metadata+0x58f/0xfa0 mm/kmsan/kmsan.c:316 kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:337 __msan_memcpy+0x5b/0x70 mm/kmsan/kmsan_instr.c:133 __mpol_dup+0x146/0x470 mm/mempolicy.c:2149 mpol_dup include/linux/mempolicy.h:91 [inline] vma_dup_policy+0x93/0x190 mm/mempolicy.c:2116 dup_mmap kernel/fork.c:529 [inline] dup_mm kernel/fork.c:1320 [inline] copy_mm kernel/fork.c:1375 [inline] copy_process+0x65e6/0xb020 kernel/fork.c:1919 _do_fork+0x384/0x1050 kernel/fork.c:2218 __do_sys_clone kernel/fork.c:2325 [inline] __se_sys_clone+0xf6/0x110 kernel/fork.c:2319 __x64_sys_clone+0x62/0x80 kernel/fork.c:2319 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_save_stack mm/kmsan/kmsan.c:219 [inline] kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:439 kmsan_memcpy_memmove_metadata+0x58f/0xfa0 mm/kmsan/kmsan.c:316 kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:337 __msan_memcpy+0x5b/0x70 mm/kmsan/kmsan_instr.c:133 __mpol_dup+0x146/0x470 mm/mempolicy.c:2149 mpol_dup include/linux/mempolicy.h:91 [inline] vma_replace_policy mm/mempolicy.c:656 [inline] mbind_range mm/mempolicy.c:728 [inline] do_mbind mm/mempolicy.c:1223 [inline] kernel_mbind+0x254d/0x31a0 mm/mempolicy.c:1347 __do_sys_mbind mm/mempolicy.c:1354 [inline] __se_sys_mbind+0x11c/0x130 mm/mempolicy.c:1350 __x64_sys_mbind+0x6e/0x90 mm/mempolicy.c:1350 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmem_cache_alloc+0x572/0xb90 mm/slub.c:2777 mpol_new mm/mempolicy.c:276 [inline] do_mbind mm/mempolicy.c:1180 [inline] kernel_mbind+0x8a7/0x31a0 mm/mempolicy.c:1347 __do_sys_mbind mm/mempolicy.c:1354 [inline] __se_sys_mbind+0x11c/0x130 mm/mempolicy.c:1350 __x64_sys_mbind+0x6e/0x90 mm/mempolicy.c:1350 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 ================================================================== --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2018-12-31 7:51 KMSAN: uninit-value in mpol_rebind_mm syzbot @ 2019-01-03 8:36 ` Vlastimil Babka 2019-01-03 8:42 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Vlastimil Babka @ 2019-01-03 8:36 UTC (permalink / raw) To: syzbot, aarcange, akpm, glider, kirill.shutemov, linux-kernel, linux-mm, linux, mhocko, rientjes, syzkaller-bugs, xieyisheng1, zhongjiang On 12/31/18 8:51 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. > git tree: kmsan > console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 > kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 > dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 > compiler: clang version 8.0.0 (trunk 349734) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com > > ================================================================== > BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] > BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 The report doesn't seem to indicate where the uninit value resides in the mempolicy object. I'll have to guess. mm/mempolicy.c:353 contains: if (!mpol_store_user_nodemask(pol) && nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't see being uninitialized after leaving mpol_new(). So I'll guess it's actually about accessing pol->w.cpuset_mems_allowed on line 354. For w.cpuset_mems_allowed to be not initialized and the nodes_equal() reachable for a mempolicy where mpol_set_nodemask() is called in do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy with empty set of nodes, i.e. MPOL_LOCAL equivalent. Let's see if the patch below helps. This code is a maze to me. Note the uninit access should be benign, rebinding this kind of policy is always a no-op. ----8<---- From ff0ca29da6bc2572d7b267daa77ced6083e3f02d Mon Sep 17 00:00:00 2001 From: Vlastimil Babka <vbabka@suse.cz> Date: Thu, 3 Jan 2019 09:31:59 +0100 Subject: [PATCH] mm, mempolicy: fix uninit memory access --- mm/mempolicy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index d4496d9d34f5..a0b7487b9112 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -350,7 +350,7 @@ static void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask) { if (!pol) return; - if (!mpol_store_user_nodemask(pol) && + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL) && nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) return; -- 2.19.2 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-03 8:36 ` Vlastimil Babka @ 2019-01-03 8:42 ` Dmitry Vyukov 2019-01-03 11:14 ` Alexander Potapenko 2019-01-04 8:50 ` Vlastimil Babka 0 siblings, 2 replies; 9+ messages in thread From: Dmitry Vyukov @ 2019-01-03 8:42 UTC (permalink / raw) To: Vlastimil Babka Cc: syzbot, Andrea Arcangeli, Andrew Morton, Alexander Potapenko, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, xieyisheng1, zhong jiang On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@suse.cz> wrote: > > > On 12/31/18 8:51 AM, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. > > git tree: kmsan > > console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 > > dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 > > compiler: clang version 8.0.0 (trunk 349734) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com > > > > ================================================================== > > BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] > > BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 > > The report doesn't seem to indicate where the uninit value resides in > the mempolicy object. Yes, it doesn't and it's not trivial to do. The tool reports uses of unint _values_. Values don't necessary reside in memory. It can be a register, that come from another register that was calculated as a sum of two other values, which may come from a function argument, etc. > I'll have to guess. mm/mempolicy.c:353 contains: > > if (!mpol_store_user_nodemask(pol) && > nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) > > "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't > see being uninitialized after leaving mpol_new(). So I'll guess it's > actually about accessing pol->w.cpuset_mems_allowed on line 354. > > For w.cpuset_mems_allowed to be not initialized and the nodes_equal() > reachable for a mempolicy where mpol_set_nodemask() is called in > do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy > with empty set of nodes, i.e. MPOL_LOCAL equivalent. Let's see if the > patch below helps. This code is a maze to me. Note the uninit access > should be benign, rebinding this kind of policy is always a no-op. > > ----8<---- > From ff0ca29da6bc2572d7b267daa77ced6083e3f02d Mon Sep 17 00:00:00 2001 > From: Vlastimil Babka <vbabka@suse.cz> > Date: Thu, 3 Jan 2019 09:31:59 +0100 > Subject: [PATCH] mm, mempolicy: fix uninit memory access > > --- > mm/mempolicy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > index d4496d9d34f5..a0b7487b9112 100644 > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -350,7 +350,7 @@ static void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask) > { > if (!pol) > return; > - if (!mpol_store_user_nodemask(pol) && > + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL) && > nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) > return; > > -- > 2.19.2 > > -- > 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@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/a71997c3-e8ae-a787-d5ce-3db05768b27c%40suse.cz. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-03 8:42 ` Dmitry Vyukov @ 2019-01-03 11:14 ` Alexander Potapenko 2019-01-03 11:41 ` Vlastimil Babka 2019-01-04 8:50 ` Vlastimil Babka 1 sibling, 1 reply; 9+ messages in thread From: Alexander Potapenko @ 2019-01-03 11:14 UTC (permalink / raw) To: Dmitry Vyukov Cc: Vlastimil Babka, syzbot, Andrea Arcangeli, Andrew Morton, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, Yisheng Xie, zhong jiang On Thu, Jan 3, 2019 at 9:42 AM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@suse.cz> wrote: > > > > > > On 12/31/18 8:51 AM, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. > > > git tree: kmsan > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 > > > compiler: clang version 8.0.0 (trunk 349734) > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com > > > > > > ================================================================== > > > BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] > > > BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 > > > > The report doesn't seem to indicate where the uninit value resides in > > the mempolicy object. > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > unint _values_. Values don't necessary reside in memory. It can be a > register, that come from another register that was calculated as a sum > of two other values, which may come from a function argument, etc. > > > I'll have to guess. mm/mempolicy.c:353 contains: > > > > if (!mpol_store_user_nodemask(pol) && > > nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) > > > > "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't > > see being uninitialized after leaving mpol_new(). So I'll guess it's > > actually about accessing pol->w.cpuset_mems_allowed on line 354. > > > > For w.cpuset_mems_allowed to be not initialized and the nodes_equal() > > reachable for a mempolicy where mpol_set_nodemask() is called in > > do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy > > with empty set of nodes, i.e. MPOL_LOCAL equivalent. Let's see if the > > patch below helps. This code is a maze to me. Note the uninit access > > should be benign, rebinding this kind of policy is always a no-op. If I'm reading mempolicy.c right, `pol->flags & MPOL_F_LOCAL` doesn't imply `pol->mode == MPOL_PREFERRED`, shouldn't we check for both here? > > ----8<---- > > From ff0ca29da6bc2572d7b267daa77ced6083e3f02d Mon Sep 17 00:00:00 2001 > > From: Vlastimil Babka <vbabka@suse.cz> > > Date: Thu, 3 Jan 2019 09:31:59 +0100 > > Subject: [PATCH] mm, mempolicy: fix uninit memory access > > > > --- > > mm/mempolicy.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > > index d4496d9d34f5..a0b7487b9112 100644 > > --- a/mm/mempolicy.c > > +++ b/mm/mempolicy.c > > @@ -350,7 +350,7 @@ static void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask) > > { > > if (!pol) > > return; > > - if (!mpol_store_user_nodemask(pol) && > > + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL) && > > nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) > > return; > > > > -- > > 2.19.2 > > > > -- > > 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@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/a71997c3-e8ae-a787-d5ce-3db05768b27c%40suse.cz. > > For more options, visit https://groups.google.com/d/optout. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-03 11:14 ` Alexander Potapenko @ 2019-01-03 11:41 ` Vlastimil Babka 0 siblings, 0 replies; 9+ messages in thread From: Vlastimil Babka @ 2019-01-03 11:41 UTC (permalink / raw) To: Alexander Potapenko, Dmitry Vyukov Cc: syzbot, Andrea Arcangeli, Andrew Morton, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, Yisheng Xie, zhong jiang On 1/3/19 12:14 PM, Alexander Potapenko wrote: > On Thu, Jan 3, 2019 at 9:42 AM Dmitry Vyukov <dvyukov@google.com> wrote: >> >> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@suse.cz> wrote: >>> >>> >>> On 12/31/18 8:51 AM, syzbot wrote: >>>> Hello, >>>> >>>> syzbot found the following crash on: >>>> >>>> HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. >>>> git tree: kmsan >>>> console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 >>>> compiler: clang version 8.0.0 (trunk 349734) >>>> >>>> Unfortunately, I don't have any reproducer for this crash yet. >>>> >>>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>>> Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com >>>> >>>> ================================================================== >>>> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] >>>> BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 >>> >>> The report doesn't seem to indicate where the uninit value resides in >>> the mempolicy object. >> >> Yes, it doesn't and it's not trivial to do. The tool reports uses of >> unint _values_. Values don't necessary reside in memory. It can be a >> register, that come from another register that was calculated as a sum >> of two other values, which may come from a function argument, etc. >> >>> I'll have to guess. mm/mempolicy.c:353 contains: >>> >>> if (!mpol_store_user_nodemask(pol) && >>> nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) >>> >>> "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't >>> see being uninitialized after leaving mpol_new(). So I'll guess it's >>> actually about accessing pol->w.cpuset_mems_allowed on line 354. >>> >>> For w.cpuset_mems_allowed to be not initialized and the nodes_equal() >>> reachable for a mempolicy where mpol_set_nodemask() is called in >>> do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy >>> with empty set of nodes, i.e. MPOL_LOCAL equivalent. Let's see if the >>> patch below helps. This code is a maze to me. Note the uninit access >>> should be benign, rebinding this kind of policy is always a no-op. > If I'm reading mempolicy.c right, `pol->flags & MPOL_F_LOCAL` doesn't > imply `pol->mode == MPOL_PREFERRED`, shouldn't we check for both here? I think it does? Only preferred mempolicies set it, including default_policy, and MPOL_LOCAL is converted to MPOL_PREFERRED internally. Anyway we would need the opposite implication here to be safe, and that's also true. >>> ----8<---- >>> From ff0ca29da6bc2572d7b267daa77ced6083e3f02d Mon Sep 17 00:00:00 2001 >>> From: Vlastimil Babka <vbabka@suse.cz> >>> Date: Thu, 3 Jan 2019 09:31:59 +0100 >>> Subject: [PATCH] mm, mempolicy: fix uninit memory access >>> >>> --- >>> mm/mempolicy.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c >>> index d4496d9d34f5..a0b7487b9112 100644 >>> --- a/mm/mempolicy.c >>> +++ b/mm/mempolicy.c >>> @@ -350,7 +350,7 @@ static void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask) >>> { >>> if (!pol) >>> return; >>> - if (!mpol_store_user_nodemask(pol) && >>> + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL) && >>> nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) >>> return; >>> >>> -- >>> 2.19.2 >>> >>> -- >>> 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@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/a71997c3-e8ae-a787-d5ce-3db05768b27c%40suse.cz. >>> For more options, visit https://groups.google.com/d/optout. > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-03 8:42 ` Dmitry Vyukov 2019-01-03 11:14 ` Alexander Potapenko @ 2019-01-04 8:50 ` Vlastimil Babka 2019-01-04 8:57 ` Dmitry Vyukov 2019-01-05 1:28 ` Andrew Morton 1 sibling, 2 replies; 9+ messages in thread From: Vlastimil Babka @ 2019-01-04 8:50 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, Andrea Arcangeli, Andrew Morton, Alexander Potapenko, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, xieyisheng1, zhong jiang On 1/3/19 9:42 AM, Dmitry Vyukov wrote: > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@suse.cz> wrote: >> >> >> On 12/31/18 8:51 AM, syzbot wrote: >>> Hello, >>> >>> syzbot found the following crash on: >>> >>> HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. >>> git tree: kmsan >>> console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 >>> dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 >>> compiler: clang version 8.0.0 (trunk 349734) >>> >>> Unfortunately, I don't have any reproducer for this crash yet. >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com >>> >>> ================================================================== >>> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] >>> BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 >> >> The report doesn't seem to indicate where the uninit value resides in >> the mempolicy object. > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > unint _values_. Values don't necessary reside in memory. It can be a > register, that come from another register that was calculated as a sum > of two other values, which may come from a function argument, etc. I see. BTW, the patch I sent will be picked up for testing, or does it have to be in mmotm/linux-next first? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-04 8:50 ` Vlastimil Babka @ 2019-01-04 8:57 ` Dmitry Vyukov 2019-01-05 1:28 ` Andrew Morton 1 sibling, 0 replies; 9+ messages in thread From: Dmitry Vyukov @ 2019-01-04 8:57 UTC (permalink / raw) To: Vlastimil Babka Cc: syzbot, Andrea Arcangeli, Andrew Morton, Alexander Potapenko, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, xieyisheng1, zhong jiang On Fri, Jan 4, 2019 at 9:50 AM Vlastimil Babka <vbabka@suse.cz> wrote: > > On 1/3/19 9:42 AM, Dmitry Vyukov wrote: > > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vbabka@suse.cz> wrote: > >> > >> > >> On 12/31/18 8:51 AM, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following crash on: > >>> > >>> HEAD commit: 79fc24ff6184 kmsan: highmem: use kmsan_clear_page() in cop.. > >>> git tree: kmsan > >>> console output: https://syzkaller.appspot.com/x/log.txt?x=13c48b67400000 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=901dd030b2cc57e7 > >>> dashboard link: https://syzkaller.appspot.com/bug?extid=b19c2dc2c990ea657a71 > >>> compiler: clang version 8.0.0 (trunk 349734) > >>> > >>> Unfortunately, I don't have any reproducer for this crash yet. > >>> > >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >>> Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com > >>> > >>> ================================================================== > >>> BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] > >>> BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 > >> > >> The report doesn't seem to indicate where the uninit value resides in > >> the mempolicy object. > > > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > > unint _values_. Values don't necessary reside in memory. It can be a > > register, that come from another register that was calculated as a sum > > of two other values, which may come from a function argument, etc. > > I see. BTW, the patch I sent will be picked up for testing, or does it > have to be in mmotm/linux-next first? It needs to be in upstream tree. Since KMSAN is not upstream, we have only 1 branch that is based on upstream and is periodically rebased: https://github.com/google/kmsan If the bug would have a repro, then we could ask syzbot to test this patch on top of KMSAN tree. But unfortunately it doesn't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-04 8:50 ` Vlastimil Babka 2019-01-04 8:57 ` Dmitry Vyukov @ 2019-01-05 1:28 ` Andrew Morton 2019-01-15 10:06 ` Vlastimil Babka 1 sibling, 1 reply; 9+ messages in thread From: Andrew Morton @ 2019-01-05 1:28 UTC (permalink / raw) To: Vlastimil Babka Cc: Dmitry Vyukov, syzbot, Andrea Arcangeli, Alexander Potapenko, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, xieyisheng1, zhong jiang On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka <vbabka@suse.cz> wrote: > > Yes, it doesn't and it's not trivial to do. The tool reports uses of > > unint _values_. Values don't necessary reside in memory. It can be a > > register, that come from another register that was calculated as a sum > > of two other values, which may come from a function argument, etc. > > I see. BTW, the patch I sent will be picked up for testing, or does it > have to be in mmotm/linux-next first? I grabbed it. To go further we'd need a changelog, a signoff, description of testing status, reviews, a Fixes: and perhaps a cc:stable ;) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm 2019-01-05 1:28 ` Andrew Morton @ 2019-01-15 10:06 ` Vlastimil Babka 0 siblings, 0 replies; 9+ messages in thread From: Vlastimil Babka @ 2019-01-15 10:06 UTC (permalink / raw) To: Andrew Morton Cc: Dmitry Vyukov, syzbot, Andrea Arcangeli, Alexander Potapenko, Kirill A. Shutemov, LKML, Linux-MM, linux, Michal Hocko, David Rientjes, syzkaller-bugs, xieyisheng1, zhong jiang On 1/5/19 2:28 AM, Andrew Morton wrote: > On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka <vbabka@suse.cz> wrote: > >>> Yes, it doesn't and it's not trivial to do. The tool reports uses of >>> unint _values_. Values don't necessary reside in memory. It can be a >>> register, that come from another register that was calculated as a sum >>> of two other values, which may come from a function argument, etc. >> >> I see. BTW, the patch I sent will be picked up for testing, or does it >> have to be in mmotm/linux-next first? > > I grabbed it. To go further we'd need a changelog, a signoff, > description of testing status, reviews, a Fixes: and perhaps a > cc:stable ;) Here's the full patch. Since there was no reproducer, there probably won't be any conclusive testing, but we might interpret lack of further KSMSAN reports as a success :) ----8<---- From 81ad0c822cb022cacea9b69565e12aac96dfb3fc Mon Sep 17 00:00:00 2001 From: Vlastimil Babka <vbabka@suse.cz> Date: Thu, 3 Jan 2019 09:31:59 +0100 Subject: [PATCH] mm, mempolicy: fix uninit memory access Syzbot with KMSAN reports (excerpt): ================================================================== BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:353 [inline] BUG: KMSAN: uninit-value in mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 CPU: 1 PID: 17420 Comm: syz-executor4 Not tainted 4.20.0-rc7+ #15 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x173/0x1d0 lib/dump_stack.c:113 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613 __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:295 mpol_rebind_policy mm/mempolicy.c:353 [inline] mpol_rebind_mm+0x249/0x370 mm/mempolicy.c:384 update_tasks_nodemask+0x608/0xca0 kernel/cgroup/cpuset.c:1120 update_nodemasks_hier kernel/cgroup/cpuset.c:1185 [inline] update_nodemask kernel/cgroup/cpuset.c:1253 [inline] cpuset_write_resmask+0x2a98/0x34b0 kernel/cgroup/cpuset.c:1728 ... Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176 kmem_cache_alloc+0x572/0xb90 mm/slub.c:2777 mpol_new mm/mempolicy.c:276 [inline] do_mbind mm/mempolicy.c:1180 [inline] kernel_mbind+0x8a7/0x31a0 mm/mempolicy.c:1347 __do_sys_mbind mm/mempolicy.c:1354 [inline] As it's difficult to report where exactly the uninit value resides in the mempolicy object, we have to guess a bit. mm/mempolicy.c:353 contains this part of mpol_rebind_policy(): if (!mpol_store_user_nodemask(pol) && nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) "mpol_store_user_nodemask(pol)" is testing pol->flags, which I couldn't ever see being uninitialized after leaving mpol_new(). So I'll guess it's actually about accessing pol->w.cpuset_mems_allowed on line 354, but still part of statement starting on line 353. For w.cpuset_mems_allowed to be not initialized, and the nodes_equal() reachable for a mempolicy where mpol_set_nodemask() is called in do_mbind(), it seems the only possibility is a MPOL_PREFERRED policy with empty set of nodes, i.e. MPOL_LOCAL equivalent, with MPOL_F_LOCAL flag. Let's exclude such policies from the nodes_equal() check. Note the uninit access should be benign anyway, as rebinding this kind of policy is always a no-op. Therefore no actual need for stable inclusion. Link: http://lkml.kernel.org/r/a71997c3-e8ae-a787-d5ce-3db05768b27c@suse.cz Reported-by: syzbot+b19c2dc2c990ea657a71@syzkaller.appspotmail.com Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: David Rientjes <rientjes@google.com> Cc: Yisheng Xie <xieyisheng1@huawei.com> Cc: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- mm/mempolicy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index d4496d9d34f5..a0b7487b9112 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -350,7 +350,7 @@ static void mpol_rebind_policy(struct mempolicy *pol, const nodemask_t *newmask) { if (!pol) return; - if (!mpol_store_user_nodemask(pol) && + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL) && nodes_equal(pol->w.cpuset_mems_allowed, *newmask)) return; -- 2.20.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-15 10:06 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-31 7:51 KMSAN: uninit-value in mpol_rebind_mm syzbot 2019-01-03 8:36 ` Vlastimil Babka 2019-01-03 8:42 ` Dmitry Vyukov 2019-01-03 11:14 ` Alexander Potapenko 2019-01-03 11:41 ` Vlastimil Babka 2019-01-04 8:50 ` Vlastimil Babka 2019-01-04 8:57 ` Dmitry Vyukov 2019-01-05 1:28 ` Andrew Morton 2019-01-15 10:06 ` Vlastimil Babka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).