KMSAN: uninit-value in mpol_rebind_mm

[syzbot]

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+b19c2d...@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 syzk...@googlegroups.com.

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

[Vlastimil Babka]

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+b19c2d...@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 <vba...@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

[Dmitry Vyukov]

On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vba...@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+b19c2d...@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.

> --
> 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-bug...@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]

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?

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

[Vlastimil Babka]

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.

[Vlastimil Babka]

On 1/3/19 9:42 AM, Dmitry Vyukov wrote:
> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka <vba...@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+b19c2d...@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?

[Dmitry Vyukov]

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.

[Andrew Morton]

On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka <vba...@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 ;)

[Vlastimil Babka]

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 <vba...@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...@suse.cz
Reported-by: syzbot+b19c2d...@syzkaller.appspotmail.com
Signed-off-by: Vlastimil Babka <vba...@suse.cz>
Cc: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvy...@google.com>
Cc: Andrea Arcangeli <aarc...@redhat.com>
Cc: "Kirill A. Shutemov" <kirill....@linux.intel.com>
Cc: Michal Hocko <mho...@suse.com>
Cc: David Rientjes <rien...@google.com>
Cc: Yisheng Xie <xieyi...@huawei.com>
Cc: zhong jiang <zhong...@huawei.com>
Signed-off-by: Andrew Morton <ak...@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