[syzbot] KMSAN: uninit-value in mpol_rebind_task (2)

15 views
Skip to first unread message

syzbot

unread,
Jan 4, 2022, 5:03:18 AM1/4/22
to ak...@linux-foundation.org, gli...@google.com, linux-...@vger.kernel.org, linu...@kvack.org, syzkall...@googlegroups.com
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

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+217f79...@syzkaller.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]
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]
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
=====================================================


---
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.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Andrew Morton

unread,
Jan 5, 2022, 6:50:41 PM1/5/22
to syzbot, gli...@google.com, linux-...@vger.kernel.org, linu...@kvack.org, syzkall...@googlegroups.com
On Tue, 04 Jan 2022 02:03:17 -0800 syzbot <syzbot+217f79...@syzkaller.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+217f79...@syzkaller.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?
But mpol_new() does

policy->flags = flags;

Dmitry Vyukov

unread,
Jan 7, 2022, 8:54:33 AM1/7/22
to Andrew Morton, syzbot, gli...@google.com, linux-...@vger.kernel.org, linu...@kvack.org, syzkall...@googlegroups.com
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.
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?
Reply all
Reply to author
Forward
0 new messages