BUG: unable to handle kernel paging request in kernel_get_mempolicy

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13966e8fe00000
kernel config: https://syzkaller.appspot.com/x/.config?x=91b674b8f0368e69
dashboard link: https://syzkaller.appspot.com/bug?extid=693dc11fcb53120b5559
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1738b02be00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17d2c76de00000

The bug was bisected to:

commit 4426e945df588f2878affddf88a51259200f7e29
Author: Peter Xu <pet...@redhat.com>
Date: Thu Apr 2 04:08:49 2020 +0000

mm/gup: allow VM_FAULT_RETRY for multiple times

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14ac4a5de00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=16ac4a5de00000
console output: https://syzkaller.appspot.com/x/log.txt?x=12ac4a5de00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+693dc1...@syzkaller.appspotmail.com
Fixes: 4426e945df58 ("mm/gup: allow VM_FAULT_RETRY for multiple times")

BUG: unable to handle page fault for address: ffffffff00000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 987c067 P4D 987c067 PUD 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7181 Comm: syz-executor616 Not tainted 5.6.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:page_to_nid include/linux/mm.h:1245 [inline]
RIP: 0010:lookup_node mm/mempolicy.c:906 [inline]
RIP: 0010:do_get_mempolicy mm/mempolicy.c:970 [inline]
RIP: 0010:kernel_get_mempolicy+0x60e/0xfb0 mm/mempolicy.c:1615
Code: 88 00 07 00 00 e8 b2 35 c5 ff 4c 8b 7c 24 78 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 fb 08 00 00 <49> 8b 1f 48 c7 c7 ff ff ff ff 48 89 de e8 10 37 c5 ff 48 83 fb ff
RSP: 0018:ffffc900018d7de8 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff81adaaf1
RDX: 1fffffffe0000000 RSI: ffffffff81adaafe RDI: 0000000000000005
RBP: 0000000000000000 R08: ffff88808de924c0 R09: ffffed1011bd2499
R10: ffff88808de924c7 R11: ffffed1011bd2498 R12: 0000000000000000
R13: 1ffff9200031afc4 R14: ffffffff89a6df60 R15: ffffffff00000000
FS: 00007f848cd4a700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff00000000 CR3: 00000000a7a8d000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__do_sys_get_mempolicy mm/mempolicy.c:1633 [inline]
__se_sys_get_mempolicy mm/mempolicy.c:1629 [inline]
__x64_sys_get_mempolicy+0xba/0x150 mm/mempolicy.c:1629
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x446719
Code: e8 5c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 0b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f848cd49db8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ef
RAX: ffffffffffffffda RBX: 00000000006dbc28 RCX: 0000000000446719
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00000000006dbc20 R08: 0000000000000003 R09: 0000000000000000
R10: 000000002073b000 R11: 0000000000000246 R12: 00000000006dbc2c
R13: 00007ffcfe6ba66f R14: 00007f848cd4a9c0 R15: 20c49ba5e353f7cf
Modules linked in:
CR2: ffffffff00000000
---[ end trace 0becf554e06291c3 ]---
RIP: 0010:page_to_nid include/linux/mm.h:1245 [inline]
RIP: 0010:lookup_node mm/mempolicy.c:906 [inline]
RIP: 0010:do_get_mempolicy mm/mempolicy.c:970 [inline]
RIP: 0010:kernel_get_mempolicy+0x60e/0xfb0 mm/mempolicy.c:1615
Code: 88 00 07 00 00 e8 b2 35 c5 ff 4c 8b 7c 24 78 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 fb 08 00 00 <49> 8b 1f 48 c7 c7 ff ff ff ff 48 89 de e8 10 37 c5 ff 48 83 fb ff
RSP: 0018:ffffc900018d7de8 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff81adaaf1
RDX: 1fffffffe0000000 RSI: ffffffff81adaafe RDI: 0000000000000005
RBP: 0000000000000000 R08: ffff88808de924c0 R09: ffffed1011bd2499
R10: ffff88808de924c7 R11: ffffed1011bd2498 R12: 0000000000000000
R13: 1ffff9200031afc4 R14: ffffffff89a6df60 R15: ffffffff00000000
FS: 00007f848cd4a700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff00000000 CR3: 00000000a7a8d000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
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#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Peter Xu]

Hi, Andrew & all,

I can reproduce this locally right after I run the test program, and
below patch fixed it for me - the test program can run with quite a
few minutes without crashing again.

Is there a way I can feed this to the syzbot to re-verify this?

Thanks,

8<---------------------------------------------------------------
From 23800bff6fa346a4e9b3806dc0cfeb74498df757 Mon Sep 17 00:00:00 2001
From: Peter Xu <pet...@redhat.com>
Date: Mon, 6 Apr 2020 20:40:13 -0400
Subject: [PATCH] mm/mempolicy: Allow lookup_node() to handle fatal signal

lookup_node() uses gup to pin the page and get node information. It
checks against ret>=0 assuming the page will be filled in. However
it's also possible that gup will return zero, for example, when the
thread is quickly killed with a fatal signal. Teach lookup_node() to
gracefully return an error -EFAULT if it happens.

Reported-by: syzbot+693dc1...@syzkaller.appspotmail.com
Fixes: 4426e945df58 ("mm/gup: allow VM_FAULT_RETRY for multiple times")

Signed-off-by: Peter Xu <pet...@redhat.com>
---
mm/mempolicy.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 5fb427aed612..1398578db025 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -902,7 +902,10 @@ static int lookup_node(struct mm_struct *mm, unsigned long addr)

int locked = 1;
err = get_user_pages_locked(addr & PAGE_MASK, 1, 0, &p, &locked);
- if (err >= 0) {
+ if (err == 0) {
+ /* E.g. GUP interupted by fatal signal */
+ err = -EFAULT;
+ } else if (err > 0) {
err = page_to_nid(p);
put_page(p);
}
--
2.24.1


--
Peter Xu

[Randy Dunlap]

Hi Peter,

Send the patch. At the top of the email, put something like
#syz test <git repo> <branch>

It's documented here:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md

~Randy
Reported-by: Randy Dunlap <rdu...@infradead.org>

[syzbot]

want 2 args (repo, branch), got 3

> --
> 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/3ff20c8a-5a26-5e38-42f7-ec751735d47c%40infradead.org.

[syzbot]

want 2 args (repo, branch), got 3

>

[Peter Xu]

Thanks Randy.

#syz test https://github.com/xzpeter/linux.git 23800bff6fa346a4e9b3806dc0cfeb74498df757

--
Peter Xu

[Andrew Morton]

On Mon, 6 Apr 2020 20:47:45 -0400 Peter Xu <pet...@redhat.com> wrote:

> >From 23800bff6fa346a4e9b3806dc0cfeb74498df757 Mon Sep 17 00:00:00 2001
> From: Peter Xu <pet...@redhat.com>
> Date: Mon, 6 Apr 2020 20:40:13 -0400
> Subject: [PATCH] mm/mempolicy: Allow lookup_node() to handle fatal signal
>
> lookup_node() uses gup to pin the page and get node information. It
> checks against ret>=0 assuming the page will be filled in. However
> it's also possible that gup will return zero, for example, when the
> thread is quickly killed with a fatal signal. Teach lookup_node() to
> gracefully return an error -EFAULT if it happens.
>

> ...

>
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -902,7 +902,10 @@ static int lookup_node(struct mm_struct *mm, unsigned long addr)
>
> int locked = 1;
> err = get_user_pages_locked(addr & PAGE_MASK, 1, 0, &p, &locked);
> - if (err >= 0) {
> + if (err == 0) {
> + /* E.g. GUP interupted by fatal signal */
> + err = -EFAULT;
> + } else if (err > 0) {
> err = page_to_nid(p);
> put_page(p);
> }

Doh. Thanks.

Should it have been -EINTR?

[Peter Xu]

It looks ok to me too. I was returning -EFAULT to follow the same
value as get_vaddr_frames() (which is the other caller of
get_user_pages_locked()). So far the only path that I found can
trigger this is when there's a fatal signal pending right after the
gup. If so, the userspace won't have a chance to see the -EINTR (or
whatever we return) anyways.

Thanks,

--
Peter Xu

[Andrew Morton]

Yup. I guess we're a victim of get_user_pages()'s screwy return value
conventions - the caller cannot distinguish between invalid-addr and
fatal-signal.

Which makes one wonder why lookup_node() ever worked. What happens if
get_mempolicy(MPOL_F_NODE) is passed a wild userspace address?

[Peter Xu]

Indeed.

>
> Which makes one wonder why lookup_node() ever worked. What happens if
> get_mempolicy(MPOL_F_NODE) is passed a wild userspace address?
>

I'm not familiar with mempolicy at all, but do you mean MPOL_F_NODE
with MPOL_F_ADDR? Asked since iiuc if only MPOL_F_NODE is specified,
the kernel should not use the userspace addr at all (which seems to be
the thing we do now). get_mempolicy(MPOL_F_NODE|MPOL_F_ADDR) seems to
return -EFAULT as expected, though I agree maybe it would still be
nicer to differentiate the two cases.

Thanks,

--
Peter Xu

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger crash:

Reported-and-tested-by: syzbot+693dc1...@syzkaller.appspotmail.com

Tested on:

commit: 23800bff mm/mempolicy: Allow lookup_node() to handle fatal..
git tree: https://github.com/xzpeter/linux.git
kernel config: https://syzkaller.appspot.com/x/.config?x=288d637f7bebfd40

dashboard link: https://syzkaller.appspot.com/bug?extid=693dc11fcb53120b5559
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

Note: testing is done by a robot and is best-effort only.

[Dmitry Vyukov]

Am I reading this correctly that we put an initialized struct page* in
this case? If so, with stack spraying this looks like an "interesting"
bug.

[Peter Xu]

Yeah, so far it should be fine, but... ideally I guess we should init
page==NULL in lookup_node() too to avoid potential risk on exploiting.
Maybe we could squash this into the fix if still possible.

Thanks,

--
Peter Xu