mm: fault in __do_fault
Subsystems (2)
Hello,
The following program triggers GPF in __do_fault:
https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
general protection fault: 0000 [#1] SMP KASAN Modules linked in: CPU: 3 PID: 2955 Comm: a.out Not tainted 4.10.0+ #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88006b4e2480 task.stack: ffff88006b0b0000 RIP: 0010:__read_once_size include/linux/compiler.h:247 [inline] RIP: 0010:compound_head include/linux/page-flags.h:146 [inline] RIP: 0010:trylock_page include/linux/pagemap.h:442 [inline] RIP: 0010:lock_page include/linux/pagemap.h:452 [inline] RIP: 0010:__do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: 0000:ffff88006b0b7470 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 1ffff1000d616e91 RCX: 0000000000000000 RDX: 0000000000000004 RSI: dffffc0000000000 RDI: 0000000000000020 RBP: ffff88006b0b7550 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000004 R12: ffff88006b0b74e8 R13: 0000000000000000 R14: ffff88006b0b7528 R15: 0000000000000000 FS: 00007fef8bb55700(0000) GS:ffff88006d180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020012fe0 CR3: 000000006a8dc000 CR4: 00000000001406e0 Call Trace: do_read_fault mm/memory.c:3266 [inline] do_fault+0x5ee/0x2080 mm/memory.c:3366 handle_pte_fault mm/memory.c:3596 [inline] __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3710 handle_mm_fault+0x1e2/0x480 mm/memory.c:3747 __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1396 trace_do_page_fault+0x141/0x6c0 arch/x86/mm/fault.c:1489 do_async_page_fault+0x72/0xc0 arch/x86/kernel/kvm.c:264 async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1014 RIP: 0033:0x43dda0 RSP: 002b:00007fef8bb54878 EFLAGS: 00010202 RAX: 00007fef8bb548b0 RBX: 0000000000000000 RCX: 000000000000000e RDX: 0000000000000400 RSI: 0000000020012fe0 RDI: 00007fef8bb548b0 RBP: 00007fef8bb54cd0 R08: 0000000000000400 R09: 00007fef8bb54d10 R10: 00007fef8bb559d0 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fef8bb559c0 R15: 00007fef8bb55700 Code: 00 e8 0e 35 b8 ff e8 79 09 a2 02 4c 89 e2 49 8d 7f 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 c6 04 02 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc RIP: __read_once_size include/linux/compiler.h:247 [inline] RSP: ffff88006b0b7470 RIP: compound_head include/linux/page-flags.h:146 [inline] RSP: ffff88006b0b7470 RIP: trylock_page include/linux/pagemap.h:442 [inline] RSP: ffff88006b0b7470 RIP: lock_page include/linux/pagemap.h:452 [inline] RSP: ffff88006b0b7470 RIP: __do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: ffff88006b0b7470 ---[ end trace d24250eecdbb8a34 ]---
On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 42 lines · Dmitry Vyukov
Hello,
The following program triggers GPF in
__do_fault:
https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txtgeneral protection fault: 0000 [#1] SMP KASAN Modules linked in: CPU: 3 PID: 2955 Comm: a.out Not tainted 4.10.0+ #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88006b4e2480 task.stack: ffff88006b0b0000 RIP: 0010:__read_once_size include/linux/compiler.h:247 [inline] RIP: 0010:compound_head include/linux/page-flags.h:146 [inline] RIP: 0010:trylock_page include/linux/pagemap.h:442 [inline] RIP: 0010:lock_page include/linux/pagemap.h:452 [inline] RIP: 0010:__do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: 0000:ffff88006b0b7470 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 1ffff1000d616e91 RCX: 0000000000000000 RDX: 0000000000000004 RSI: dffffc0000000000 RDI: 0000000000000020 RBP: ffff88006b0b7550 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000004 R12: ffff88006b0b74e8 R13: 0000000000000000 R14: ffff88006b0b7528 R15: 0000000000000000 FS: 00007fef8bb55700(0000) GS:ffff88006d180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020012fe0 CR3: 000000006a8dc000 CR4: 00000000001406e0 Call Trace: do_read_fault mm/memory.c:3266 [inline] do_fault+0x5ee/0x2080 mm/memory.c:3366 handle_pte_fault mm/memory.c:3596 [inline] __handle_mm_fault+0x1062/0x2cb0 mm/memory.c:3710 handle_mm_fault+0x1e2/0x480 mm/memory.c:3747 __do_page_fault+0x4f6/0xb60 arch/x86/mm/fault.c:1396 trace_do_page_fault+0x141/0x6c0 arch/x86/mm/fault.c:1489 do_async_page_fault+0x72/0xc0 arch/x86/kernel/kvm.c:264 async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:1014 RIP: 0033:0x43dda0 RSP: 002b:00007fef8bb54878 EFLAGS: 00010202 RAX: 00007fef8bb548b0 RBX: 0000000000000000 RCX: 000000000000000e RDX: 0000000000000400 RSI: 0000000020012fe0 RDI: 00007fef8bb548b0 RBP: 00007fef8bb54cd0 R08: 0000000000000400 R09: 00007fef8bb54d10 R10: 00007fef8bb559d0 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fef8bb559c0 R15: 00007fef8bb55700 Code: 00 e8 0e 35 b8 ff e8 79 09 a2 02 4c 89 e2 49 8d 7f 20 48 b8 00
Quoted 8 lines
00 00 00 00 fc ff df 48 c1 ea 03 c6 04 02 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc
RIP: __read_once_size include/linux/compiler.h:247 [inline] RSP: ffff88006b0b7470 RIP: compound_head include/linux/page-flags.h:146 [inline] RSP: ffff88006b0b7470 RIP: trylock_page include/linux/pagemap.h:442 [inline] RSP: ffff88006b0b7470 RIP: lock_page include/linux/pagemap.h:452 [inline] RSP: ffff88006b0b7470 RIP: __do_fault+0x247/0x3e0 mm/memory.c:2898 RSP: ffff88006b0b7470
__do_fault() expects to see a page if ->fault() returns zero, but handle_userfault() mess this up, making shmem_fault() return 0 without setting vmf->page.
I'm not entirely sure it's fully correct, but the patch below fixes the crash for me.
Andrea, does it look okay for you?
fs/userfaultfd.c +1 -1
@@ -489,7 +489,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)* in such case. */ down_read (&mm->mmap_sem); - ret =0 ; + ret =VM_FAULT_NOPAGE ; } }
Signature · 7 lines
Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 7 lines · Kirill A. Shutemov
Andrea, does it look okay for you?
fs/userfaultfd.c +0
-0
fs/userfaultfd.c int handle_userfault(struct vm_fault *vmf, unsigned long reason) · line 494
Quoted 7 lines
fs/userfaultfd.c +1
-1@@ -489,7 +489,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)* in such case. */ down_read (&mm->mmap_sem); - ret =0 ; + ret =VM_FAULT_NOPAGE ; } }
Yes, I did the same fix.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Hello Dmitry,
Quoted 4 lines · Dmitry Vyukov
Hello,
The following program triggers GPF in
__do_fault:
https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txt
Can you verify this fix:
Quoted 9 lines · Andrea Arcangeli
Hello Dmitry,
Quoted 4 lines · Dmitry Vyukov
Hello,
The following program triggers GPF in
__do_fault:
https://gist.githubusercontent.com/dvyukov/27345737fca18d92ef761e7fa08aec9b/raw/d99d02511d0bf9a8d6f6bd9c79d373a26924e974/gistfile1.txtCan you verify this fix:
Applied the patch on bots.
Quoted 37 lines
From
a65381bc86d2963713b6a9c4a73cded7dd184282Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <[email protected]>
Date: Tue, 28 Feb 2017 16:36:59 +0100
Subject: [PATCH 1/1] userfaultfd: shmem:__do_faultrequiresVM_FAULT_NOPAGE
__do_faultassumesvmf->pagehas been initialized and is valid ifVM_FAULT_NOPAGEis not returned byvma->vm_ops->fault(vma, vmf).
handle_userfault()in turn should returnVM_FAULT_NOPAGEif it doesn't returnVM_FAULT_SIGBUSorVM_FAULT_RETRY(the other two possibilities).This
VM_FAULT_NOPAGEcase is only invoked when signal are pending and it didn't matter for anonymous memory before. It only started to matter since shmem was introduced. hugetlbfs also takes a different path and doesn't exercise__do_fault.Signed-off-by Andrea Arcangeli <[email protected]>--- fs/userfaultfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)fs/userfaultfd.c +1
-2@@ -500,7 +500,7 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)* in such case. */ down_read (&mm->mmap_sem); - ret =0 ; + ret =VM_FAULT_NOPAGE ; } } --
Quoted 3 lines
You received this message because you are subscribed to the Google Groups "syzkaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>