linux-kernel - Re: [syzbot] KMSAN: uninit-value in mpol_rebind

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 7 Jan 2022 14:54:20 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     syzbot <syzbot+217f792c92599518a2ab@...kaller.appspotmail.com>,
        glider@...gle.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] KMSAN: uninit-value in mpol_rebind_task (2)

On Thu, 6 Jan 2022 at 00:50, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Tue, 04 Jan 2022 02:03:17 -0800 syzbot <syzbot+217f792c92599518a2ab@...kaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    81c325bbf94e kmsan: hooks: do not check memory in kmsan_in..
> > git tree:       https://github.com/google/kmsan.git master
> > console output: https://syzkaller.appspot.com/x/log.txt?x=112b8f7db00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=2d8b9a11641dc9aa
> > dashboard link: https://syzkaller.appspot.com/bug?extid=217f792c92599518a2ab
> > compiler:       clang version 14.0.0 (/usr/local/google/src/llvm-git-monorepo 2b554920f11c8b763cd9ed9003f4e19b919b8e1f), GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13366ea5b00000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14526cb3b00000
>
> Thanks.  I don't get it.
>
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+217f792c92599518a2ab@...kaller.appspotmail.com
> >
> > =====================================================
> > BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]
> > BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368
> >  mpol_rebind_policy mm/mempolicy.c:352 [inline]
>
> Appears to be
>
>         if (!mpol_store_user_nodemask(pol) &&
>
> But if so, why didn't it also report
>
>         mpol_store_user_nodemask mm/mempolicy.c:184 [inline]
>
> which is where the
>
>         return pol->flags & MPOL_MODE_FLAGS;
>
> actually happened?

Hi Andrew,

KMSAN doesn't just flag loads of non-stored to variables. It tracks
propagation of uninit values of memory and registers and flags only
"uses" of uninit values. Where uses are roughly when uninits affect
control flow, are part of dereferenced pointers or sink to user-space.
The problem is that real code tends to load, stores and even do
computations on uninit values (or partially uninit values) a lot.
Think of bitfields, alignment paddings, or just tricky structured
code.

That's why:
return pol->flags & MPOL_MODE_FLAGS;
is not yet flagged, it just marks the result as uninit.



> >  mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368
> >  cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline]
> >  cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278
> >  cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515
> >  cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline]
> >  cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804
> >  __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520
> >  cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539
> >  cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852
> >  kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296
> >  call_write_iter include/linux/fs.h:2162 [inline]
> >  new_sync_write fs/read_write.c:503 [inline]
> >  vfs_write+0x1318/0x2030 fs/read_write.c:590
> >  ksys_write+0x28b/0x510 fs/read_write.c:643
> >  __do_sys_write fs/read_write.c:655 [inline]
> >  __se_sys_write fs/read_write.c:652 [inline]
> >  __x64_sys_write+0xdb/0x120 fs/read_write.c:652
> >  do_syscall_x64 arch/x86/entry/common.c:51 [inline]
> >  do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
> >  entry_SYSCALL_64_after_hwframe+0x44/0xae
> >
> > Uninit was created at:
> >  slab_post_alloc_hook mm/slab.h:524 [inline]
> >  slab_alloc_node mm/slub.c:3251 [inline]
> >  slab_alloc mm/slub.c:3259 [inline]
> >  kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264
> >  mpol_new mm/mempolicy.c:293 [inline]
>
> But mpol_new() does
>
>         policy->flags = flags;

I suspect the tool points at nodes field (but line 352 rather than 353
because the && that produces the final uninit value used for control
flow in on 352).

Is it possible that flags contain MPOL_MODE_FLAGS, but mode is
MPOL_LOCAL so that nodes are not set or something along these lines?


> >  do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853
> >  kernel_set_mempolicy mm/mempolicy.c:1504 [inline]
> >  __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline]
> >  __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507
> >  __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507
> >  do_syscall_x64 arch/x86/entry/common.c:51 [inline]
> >  do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
> >  entry_SYSCALL_64_after_hwframe+0x44/0xae
> >
> > CPU: 1 PID: 3479 Comm: syz-executor124 Not tainted 5.16.0-rc5-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > =====================================================