general protection fault in get_futex_key

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 763dede1 Merge tag 'for-linus-5.7-rc1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=136a055de00000
kernel config: https://syzkaller.appspot.com/x/.config?x=12205d036cec317f
dashboard link: https://syzkaller.appspot.com/bug?extid=a95c7753605c9d219466
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1578287de00000

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=1707878fe00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=1487878fe00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1087878fe00000

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

general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 8869 Comm: syz-executor.1 Not tainted 5.6.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
RIP: 0010:compound_head include/linux/page-flags.h:174 [inline]
RIP: 0010:get_futex_key+0x2cd/0x1670 kernel/futex.c:574
Code: 0b 00 31 ff 89 ee e8 e2 81 0b 00 85 ed 0f 88 65 10 00 00 e8 65 80 0b 00 4c 8b 74 24 60 49 8d 46 08 48 89 44 24 10 48 c1 e8 03 <80> 3c 18 00 0f 85 5d 11 00 00 4d 8b 66 08 31 ff 4c 89 f5 4d 89 e5
RSP: 0018:ffffc90005be78f0 EFLAGS: 00010202
RAX: 0000000000000002 RBX: dffffc0000000000 RCX: ffffffff8167b0fe
RDX: 0000000000000000 RSI: ffffffff8167b10b RDI: 0000000000000005
RBP: 0000000000000000 R08: ffff8880a15185c0 R09: ffffed10142a30b9
R10: ffff8880a15185c7 R11: ffffed10142a30b8 R12: ffffc90005be7950
R13: 0000000000000000 R14: 0000000000000008 R15: 000000002000c000
FS: 00007fe0f408b700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe0f4006db8 CR3: 00000000930c4000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
futex_lock_pi+0x19b/0x840 kernel/futex.c:2823
do_futex+0xa14/0x1ad0 kernel/futex.c:3821
__do_sys_futex kernel/futex.c:3869 [inline]
__se_sys_futex kernel/futex.c:3837 [inline]
__x64_sys_futex+0x376/0x4f0 kernel/futex.c:3837
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45c889
Code: ad b6 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 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fe0f408ac78 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: ffffffffffffffda RBX: 00007fe0f408b6d4 RCX: 000000000045c889
RDX: 0000000000000000 RSI: 0000800000000006 RDI: 000000002000cffc
RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000000e8 R14: 00000000004c3730 R15: 000000000076bf0c
Modules linked in:
---[ end trace d1f294da398e534e ]---
RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
RIP: 0010:compound_head include/linux/page-flags.h:174 [inline]
RIP: 0010:get_futex_key+0x2cd/0x1670 kernel/futex.c:574
Code: 0b 00 31 ff 89 ee e8 e2 81 0b 00 85 ed 0f 88 65 10 00 00 e8 65 80 0b 00 4c 8b 74 24 60 49 8d 46 08 48 89 44 24 10 48 c1 e8 03 <80> 3c 18 00 0f 85 5d 11 00 00 4d 8b 66 08 31 ff 4c 89 f5 4d 89 e5
RSP: 0018:ffffc90005be78f0 EFLAGS: 00010202
RAX: 0000000000000002 RBX: dffffc0000000000 RCX: ffffffff8167b0fe
RDX: 0000000000000000 RSI: ffffffff8167b10b RDI: 0000000000000005
RBP: 0000000000000000 R08: ffff8880a15185c0 R09: ffffed10142a30b9
R10: ffff8880a15185c7 R11: ffffed10142a30b8 R12: ffffc90005be7950
R13: 0000000000000000 R14: 0000000000000008 R15: 000000002000c000
FS: 00007fe0f408b700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f37738be000 CR3: 00000000930c4000 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

[Thomas Gleixner]

This means that

get_user_pages_fast(address, 1, FOLL_WRITE, &page)

returned 0, which is breaking the interface:

* Returns number of pages pinned. This may be fewer than the number requested.
* If nr_pages is 0 or negative, returns 0. If no pages were pinned, returns
* -errno.

nr_pages is clearly 1. So if the call fails, the number of pinned pages
is 0 and it should return a proper error number. It did before.

From a quick look at the commit in question I assume it's the

+ if (fatal_signal_pending(current))
+ break;

which can cause that to happen.

Thanks,

tglx

[Peter Zijlstra]

On Wed, Apr 08, 2020 at 03:36:45PM +0200, Thomas Gleixner wrote:

> This means that
>
> get_user_pages_fast(address, 1, FOLL_WRITE, &page)
>
> returned 0, which is breaking the interface:
>
> * Returns number of pages pinned. This may be fewer than the number requested.
> * If nr_pages is 0 or negative, returns 0. If no pages were pinned, returns
> * -errno.
>
> nr_pages is clearly 1. So if the call fails, the number of pinned pages
> is 0 and it should return a proper error number. It did before.
>
> From a quick look at the commit in question I assume it's the
>
> + if (fatal_signal_pending(current))
> + break;
>
> which can cause that to happen.

Yep, that's broken. It wants the below, just like all the other error
paths in that loop.

---
Subject: mm/gup: Fix broken fatal_signal_pending() test

Just like all the other error returns in this loop, we need to set
pages_done to the error value when it is zero.

Fixes: 4426e945df58 ("mm/gup: allow VM_FAULT_RETRY for multiple times")

Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
---
diff --git a/mm/gup.c b/mm/gup.c
index afce0bc47e70..14bce270b249 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1326,8 +1326,11 @@ static __always_inline long __get_user_pages_locked(struct task_struct *tsk,
* start trying again otherwise it can loop forever.
*/

- if (fatal_signal_pending(current))
+ if (fatal_signal_pending(current)) {
+ if (!pages_done)
+ pages_done = -ERESTARTSYS;
break;
+ }

ret = down_read_killable(&mm->mmap_sem);
if (ret) {

[Peter Xu]

On Wed, Apr 08, 2020 at 03:36:45PM +0200, Thomas Gleixner wrote:

Right, sorry for the mess.

Hillf has posted a fix already in the other thread (with you CCed).
So I'm marking this one as a dup now.

#syz dup: WARNING in af_alg_make_sg

Thanks,

--
Peter Xu