* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-03 8:42 ` Dmitry Vyukov
@ 2019-01-03 8:42 ` Dmitry Vyukov
2019-01-03 11:14 ` Alexander Potapenko
2019-01-04 8:50 ` Vlastimil Babka
2 siblings, 0 replies; 15+ 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] 15+ messages in thread* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-03 8:42 ` Dmitry Vyukov
2019-01-03 8:42 ` Dmitry Vyukov
@ 2019-01-03 11:14 ` Alexander Potapenko
2019-01-03 11:14 ` Alexander Potapenko
2019-01-03 11:41 ` Vlastimil Babka
2019-01-04 8:50 ` Vlastimil Babka
2 siblings, 2 replies; 15+ 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] 15+ messages in thread* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-03 11:14 ` Alexander Potapenko
@ 2019-01-03 11:14 ` Alexander Potapenko
2019-01-03 11:41 ` Vlastimil Babka
1 sibling, 0 replies; 15+ 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] 15+ messages in thread* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-03 11:14 ` Alexander Potapenko
2019-01-03 11:14 ` Alexander Potapenko
@ 2019-01-03 11:41 ` Vlastimil Babka
1 sibling, 0 replies; 15+ 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] 15+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-03 8:42 ` Dmitry Vyukov
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
2 siblings, 2 replies; 15+ 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] 15+ 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-04 8:57 ` Dmitry Vyukov
2019-01-05 1:28 ` Andrew Morton
1 sibling, 1 reply; 15+ 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] 15+ messages in thread
* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-04 8:57 ` Dmitry Vyukov
@ 2019-01-04 8:57 ` Dmitry Vyukov
0 siblings, 0 replies; 15+ 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] 15+ 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; 15+ 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] 15+ 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
2019-01-15 10:06 ` Vlastimil Babka
0 siblings, 1 reply; 15+ 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] 15+ messages in thread* Re: KMSAN: uninit-value in mpol_rebind_mm
2019-01-15 10:06 ` Vlastimil Babka
@ 2019-01-15 10:06 ` Vlastimil Babka
0 siblings, 0 replies; 15+ 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] 15+ messages in thread