Re: KMSAN: uninit-value in mpol_rebind_mm
On 1/5/19 2:28 AM, Andrew Morton wrote:
> On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka 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
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-3db05768b...@suse.cz
Reported-by: syzbot+b19c2dc2c990ea657...@syzkaller.appspotmail.com
Signed-off-by: Vlastimil Babka
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrea Arcangeli
Cc: "Kirill A. Shutemov"
Cc: Michal Hocko
Cc: David Rientjes
Cc: Yisheng Xie
Cc: zhong jiang
Signed-off-by: Andrew Morton
---
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
Re: KMSAN: uninit-value in mpol_rebind_mm
On Fri, 4 Jan 2019 09:50:31 +0100 Vlastimil Babka 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 ;)
Re: KMSAN: uninit-value in mpol_rebind_mm
On Fri, Jan 4, 2019 at 9:50 AM Vlastimil Babka wrote: > > On 1/3/19 9:42 AM, Dmitry Vyukov wrote: > > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka 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=13c48b6740 > >>> 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+b19c2dc2c990ea657...@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.
Re: KMSAN: uninit-value in mpol_rebind_mm
On 1/3/19 9:42 AM, Dmitry Vyukov wrote: > On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka 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=13c48b6740 >>> 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+b19c2dc2c990ea657...@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?
Re: KMSAN: uninit-value in mpol_rebind_mm
On 1/3/19 12:14 PM, Alexander Potapenko wrote:
> On Thu, Jan 3, 2019 at 9:42 AM Dmitry Vyukov wrote:
>>
>> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka 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=13c48b6740
>>>> 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+b19c2dc2c990ea657...@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
>>> 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+unsubscr...@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.
>
>
>
Re: KMSAN: uninit-value in mpol_rebind_mm
On Thu, Jan 3, 2019 at 9:42 AM Dmitry Vyukov wrote:
>
> On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka 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=13c48b6740
> > > 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+b19c2dc2c990ea657...@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
> > 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+unsubscr...@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
Re: KMSAN: uninit-value in mpol_rebind_mm
On Thu, Jan 3, 2019 at 9:36 AM Vlastimil Babka 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=13c48b6740
> > 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+b19c2dc2c990ea657...@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
> 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+unsubscr...@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.
Re: KMSAN: uninit-value in mpol_rebind_mm
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=13c48b6740
> 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+b19c2dc2c990ea657...@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
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
KMSAN: uninit-value in mpol_rebind_mm
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=13c48b6740 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+b19c2dc2c990ea657...@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:7f132b74cc78 EFLAGS: 0246 ORIG_RAX: 0028 RAX: ffda RBX: 0004 RCX: 004579b9 RDX: 2080 RSI: 0005 RDI: 0004 RBP: 0073bf00 R08: R09: R10: 0001 R11: 0246 R12: 7f132b74d6d4 R13: 004c471e R14: 004d7d10 R15: 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 [
