* Re: WARNING in wp_page_copy
[not found] <000000000000a6f2030598bbe38c@google.com>
@ 2019-12-14 16:20 ` syzbot
2019-12-16 15:00 ` Daniel Borkmann
2019-12-17 20:16 ` syzbot
2020-03-24 2:47 ` syzbot
2 siblings, 1 reply; 11+ messages in thread
From: syzbot @ 2019-12-14 16:20 UTC (permalink / raw)
To: andriin, ast, bjorn.topel, bpf, daniel, davem, hawk,
jakub.kicinski, john.fastabend, jonathan.lemon, kafai,
linux-kernel, magnus.karlsson, netdev, songliubraving,
syzkaller-bugs, yhs
syzbot has found a reproducer for the following crash on:
HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
------------[ cut here ]------------
WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 cow_user_page
mm/memory.c:2229 [inline]
WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 wp_page_copy+0x10b7/0x1560
mm/memory.c:2414
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 9104 Comm: syz-executor.0 Not tainted 5.5.0-rc1-syzkaller #0
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+0x197/0x210 lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
__warn.cold+0x2f/0x3e kernel/panic.c:582
report_bug+0x289/0x300 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:174 [inline]
fixup_bug arch/x86/kernel/traps.c:169 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:cow_user_page mm/memory.c:2229 [inline]
RIP: 0010:wp_page_copy+0x10b7/0x1560 mm/memory.c:2414
Code: 4c 89 f7 ba 00 10 00 00 48 81 e6 00 f0 ff ff e8 0f e6 22 06 31 ff 41
89 c7 89 c6 e8 23 03 d3 ff 45 85 ff 74 0f e8 99 01 d3 ff <0f> 0b 4c 89 f7
e8 3f d8 22 06 e8 8a 01 d3 ff 65 4c 8b 34 25 c0 1e
RSP: 0018:ffffc90002267668 EFLAGS: 00010293
RAX: ffff8880a04c6140 RBX: ffffc90002267918 RCX: ffffffff81a22a0d
RDX: 0000000000000000 RSI: ffffffff81a22a17 RDI: 0000000000000005
RBP: ffffc900022677a8 R08: ffff8880a04c6140 R09: 0000000000000000
R10: ffffed101125cfff R11: ffff8880892e7fff R12: ffff88809e403108
R13: ffffea000224b9c0 R14: ffff8880892e7000 R15: 0000000000001000
do_wp_page+0x543/0x1540 mm/memory.c:2724
handle_pte_fault mm/memory.c:3961 [inline]
__handle_mm_fault+0x327b/0x3da0 mm/memory.c:4075
handle_mm_fault+0x3b2/0xa50 mm/memory.c:4112
do_user_addr_fault arch/x86/mm/fault.c:1441 [inline]
__do_page_fault+0x536/0xd80 arch/x86/mm/fault.c:1506
do_page_fault+0x38/0x590 arch/x86/mm/fault.c:1530
page_fault+0x39/0x40 arch/x86/entry/entry_64.S:1203
RIP: 0010:copy_user_generic_unrolled+0x89/0xc0
arch/x86/lib/copy_user_64.S:91
Code: 38 4c 89 47 20 4c 89 4f 28 4c 89 57 30 4c 89 5f 38 48 8d 76 40 48 8d
7f 40 ff c9 75 b6 89 d1 83 e2 07 c1 e9 03 74 12 4c 8b 06 <4c> 89 07 48 8d
76 08 48 8d 7f 08 ff c9 75 ee 21 d2 74 10 89 d1 8a
RSP: 0018:ffffc90002267bb8 EFLAGS: 00010206
RAX: 0000000000000001 RBX: 0000000000000018 RCX: 0000000000000003
RDX: 0000000000000000 RSI: ffffc90002267c58 RDI: 0000000020001300
RBP: ffffc90002267bf0 R08: 0000000000000000 R09: fffff5200044cf8e
R10: fffff5200044cf8d R11: ffffc90002267c6f R12: 0000000020001300
R13: ffffc90002267c58 R14: 0000000020001318 R15: 00007ffffffff000
copy_to_user include/linux/uaccess.h:152 [inline]
xsk_getsockopt+0x575/0x6c0 net/xdp/xsk.c:898
__sys_getsockopt+0x16d/0x310 net/socket.c:2174
__do_sys_getsockopt net/socket.c:2189 [inline]
__se_sys_getsockopt net/socket.c:2186 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:2186
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a909
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:00007f0ec9e9ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000000000045a909
RDX: 0000000000000007 RSI: 000000000000011b RDI: 000000000000000a
RBP: 000000000075bf20 R08: 0000000020000100 R09: 0000000000000000
R10: 0000000020001300 R11: 0000000000000246 R12: 00007f0ec9e9f6d4
R13: 00000000004c1ab5 R14: 00000000004d5f60 R15: 00000000ffffffff
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-14 16:20 ` WARNING in wp_page_copy syzbot
@ 2019-12-16 15:00 ` Daniel Borkmann
2019-12-16 15:10 ` Magnus Karlsson
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Borkmann @ 2019-12-16 15:00 UTC (permalink / raw)
To: syzbot
Cc: andriin, ast, bjorn.topel, bpf, davem, hawk, jakub.kicinski,
john.fastabend, jonathan.lemon, kafai, linux-kernel,
magnus.karlsson, netdev, songliubraving, syzkaller-bugs, yhs
On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
Bjorn / Magnus, given xsk below, PTAL, thanks!
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 cow_user_page mm/memory.c:2229
> [inline]
> WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 wp_page_copy+0x10b7/0x1560
> mm/memory.c:2414
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 9104 Comm: syz-executor.0 Not tainted 5.5.0-rc1-syzkaller #0
> 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+0x197/0x210 lib/dump_stack.c:118
> panic+0x2e3/0x75c kernel/panic.c:221
> __warn.cold+0x2f/0x3e kernel/panic.c:582
> report_bug+0x289/0x300 lib/bug.c:195
> fixup_bug arch/x86/kernel/traps.c:174 [inline]
> fixup_bug arch/x86/kernel/traps.c:169 [inline]
> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
> do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
> invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
> RIP: 0010:cow_user_page mm/memory.c:2229 [inline]
> RIP: 0010:wp_page_copy+0x10b7/0x1560 mm/memory.c:2414
> Code: 4c 89 f7 ba 00 10 00 00 48 81 e6 00 f0 ff ff e8 0f e6 22 06 31 ff 41
> 89 c7 89 c6 e8 23 03 d3 ff 45 85 ff 74 0f e8 99 01 d3 ff <0f> 0b 4c 89 f7 e8
> 3f d8 22 06 e8 8a 01 d3 ff 65 4c 8b 34 25 c0 1e
> RSP: 0018:ffffc90002267668 EFLAGS: 00010293
> RAX: ffff8880a04c6140 RBX: ffffc90002267918 RCX: ffffffff81a22a0d
> RDX: 0000000000000000 RSI: ffffffff81a22a17 RDI: 0000000000000005
> RBP: ffffc900022677a8 R08: ffff8880a04c6140 R09: 0000000000000000
> R10: ffffed101125cfff R11: ffff8880892e7fff R12: ffff88809e403108
> R13: ffffea000224b9c0 R14: ffff8880892e7000 R15: 0000000000001000
> do_wp_page+0x543/0x1540 mm/memory.c:2724
> handle_pte_fault mm/memory.c:3961 [inline]
> __handle_mm_fault+0x327b/0x3da0 mm/memory.c:4075
> handle_mm_fault+0x3b2/0xa50 mm/memory.c:4112
> do_user_addr_fault arch/x86/mm/fault.c:1441 [inline]
> __do_page_fault+0x536/0xd80 arch/x86/mm/fault.c:1506
> do_page_fault+0x38/0x590 arch/x86/mm/fault.c:1530
> page_fault+0x39/0x40 arch/x86/entry/entry_64.S:1203
> RIP: 0010:copy_user_generic_unrolled+0x89/0xc0
> arch/x86/lib/copy_user_64.S:91
> Code: 38 4c 89 47 20 4c 89 4f 28 4c 89 57 30 4c 89 5f 38 48 8d 76 40 48 8d
> 7f 40 ff c9 75 b6 89 d1 83 e2 07 c1 e9 03 74 12 4c 8b 06 <4c> 89 07 48 8d 76
> 08 48 8d 7f 08 ff c9 75 ee 21 d2 74 10 89 d1 8a
> RSP: 0018:ffffc90002267bb8 EFLAGS: 00010206
> RAX: 0000000000000001 RBX: 0000000000000018 RCX: 0000000000000003
> RDX: 0000000000000000 RSI: ffffc90002267c58 RDI: 0000000020001300
> RBP: ffffc90002267bf0 R08: 0000000000000000 R09: fffff5200044cf8e
> R10: fffff5200044cf8d R11: ffffc90002267c6f R12: 0000000020001300
> R13: ffffc90002267c58 R14: 0000000020001318 R15: 00007ffffffff000
> copy_to_user include/linux/uaccess.h:152 [inline]
> xsk_getsockopt+0x575/0x6c0 net/xdp/xsk.c:898
> __sys_getsockopt+0x16d/0x310 net/socket.c:2174
> __do_sys_getsockopt net/socket.c:2189 [inline]
> __se_sys_getsockopt net/socket.c:2186 [inline]
> __x64_sys_getsockopt+0xbe/0x150 net/socket.c:2186
> do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x45a909
> 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:00007f0ec9e9ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000000000045a909
> RDX: 0000000000000007 RSI: 000000000000011b RDI: 000000000000000a
> RBP: 000000000075bf20 R08: 0000000020000100 R09: 0000000000000000
> R10: 0000000020001300 R11: 0000000000000246 R12: 00007f0ec9e9f6d4
> R13: 00000000004c1ab5 R14: 00000000004d5f60 R15: 00000000ffffffff
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-16 15:00 ` Daniel Borkmann
@ 2019-12-16 15:10 ` Magnus Karlsson
2019-12-17 13:27 ` Magnus Karlsson
0 siblings, 1 reply; 11+ messages in thread
From: Magnus Karlsson @ 2019-12-16 15:10 UTC (permalink / raw)
To: Daniel Borkmann
Cc: syzbot, Andrii Nakryiko, Alexei Starovoitov,
Björn Töpel, bpf, David S. Miller, hawk,
Jakub Kicinski, John Fastabend, Jonathan Lemon, Martin KaFai Lau,
linux-kernel, Karlsson, Magnus, Network Development, Song Liu,
syzkaller-bugs, Yonghong Song
On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > git tree: net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
>
> Bjorn / Magnus, given xsk below, PTAL, thanks!
Thanks. I will take a look at it right away.
/Magnus
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 cow_user_page mm/memory.c:2229
> > [inline]
> > WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 wp_page_copy+0x10b7/0x1560
> > mm/memory.c:2414
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 9104 Comm: syz-executor.0 Not tainted 5.5.0-rc1-syzkaller #0
> > 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+0x197/0x210 lib/dump_stack.c:118
> > panic+0x2e3/0x75c kernel/panic.c:221
> > __warn.cold+0x2f/0x3e kernel/panic.c:582
> > report_bug+0x289/0x300 lib/bug.c:195
> > fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > fixup_bug arch/x86/kernel/traps.c:169 [inline]
> > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
> > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
> > invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
> > RIP: 0010:cow_user_page mm/memory.c:2229 [inline]
> > RIP: 0010:wp_page_copy+0x10b7/0x1560 mm/memory.c:2414
> > Code: 4c 89 f7 ba 00 10 00 00 48 81 e6 00 f0 ff ff e8 0f e6 22 06 31 ff 41
> > 89 c7 89 c6 e8 23 03 d3 ff 45 85 ff 74 0f e8 99 01 d3 ff <0f> 0b 4c 89 f7 e8
> > 3f d8 22 06 e8 8a 01 d3 ff 65 4c 8b 34 25 c0 1e
> > RSP: 0018:ffffc90002267668 EFLAGS: 00010293
> > RAX: ffff8880a04c6140 RBX: ffffc90002267918 RCX: ffffffff81a22a0d
> > RDX: 0000000000000000 RSI: ffffffff81a22a17 RDI: 0000000000000005
> > RBP: ffffc900022677a8 R08: ffff8880a04c6140 R09: 0000000000000000
> > R10: ffffed101125cfff R11: ffff8880892e7fff R12: ffff88809e403108
> > R13: ffffea000224b9c0 R14: ffff8880892e7000 R15: 0000000000001000
> > do_wp_page+0x543/0x1540 mm/memory.c:2724
> > handle_pte_fault mm/memory.c:3961 [inline]
> > __handle_mm_fault+0x327b/0x3da0 mm/memory.c:4075
> > handle_mm_fault+0x3b2/0xa50 mm/memory.c:4112
> > do_user_addr_fault arch/x86/mm/fault.c:1441 [inline]
> > __do_page_fault+0x536/0xd80 arch/x86/mm/fault.c:1506
> > do_page_fault+0x38/0x590 arch/x86/mm/fault.c:1530
> > page_fault+0x39/0x40 arch/x86/entry/entry_64.S:1203
> > RIP: 0010:copy_user_generic_unrolled+0x89/0xc0
> > arch/x86/lib/copy_user_64.S:91
> > Code: 38 4c 89 47 20 4c 89 4f 28 4c 89 57 30 4c 89 5f 38 48 8d 76 40 48 8d
> > 7f 40 ff c9 75 b6 89 d1 83 e2 07 c1 e9 03 74 12 4c 8b 06 <4c> 89 07 48 8d 76
> > 08 48 8d 7f 08 ff c9 75 ee 21 d2 74 10 89 d1 8a
> > RSP: 0018:ffffc90002267bb8 EFLAGS: 00010206
> > RAX: 0000000000000001 RBX: 0000000000000018 RCX: 0000000000000003
> > RDX: 0000000000000000 RSI: ffffc90002267c58 RDI: 0000000020001300
> > RBP: ffffc90002267bf0 R08: 0000000000000000 R09: fffff5200044cf8e
> > R10: fffff5200044cf8d R11: ffffc90002267c6f R12: 0000000020001300
> > R13: ffffc90002267c58 R14: 0000000020001318 R15: 00007ffffffff000
> > copy_to_user include/linux/uaccess.h:152 [inline]
> > xsk_getsockopt+0x575/0x6c0 net/xdp/xsk.c:898
> > __sys_getsockopt+0x16d/0x310 net/socket.c:2174
> > __do_sys_getsockopt net/socket.c:2189 [inline]
> > __se_sys_getsockopt net/socket.c:2186 [inline]
> > __x64_sys_getsockopt+0xbe/0x150 net/socket.c:2186
> > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x45a909
> > 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:00007f0ec9e9ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000000000045a909
> > RDX: 0000000000000007 RSI: 000000000000011b RDI: 000000000000000a
> > RBP: 000000000075bf20 R08: 0000000020000100 R09: 0000000000000000
> > R10: 0000000020001300 R11: 0000000000000246 R12: 00007f0ec9e9f6d4
> > R13: 00000000004c1ab5 R14: 00000000004d5f60 R15: 00000000ffffffff
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
> >
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-16 15:10 ` Magnus Karlsson
@ 2019-12-17 13:27 ` Magnus Karlsson
2019-12-17 15:40 ` Catalin Marinas
0 siblings, 1 reply; 11+ messages in thread
From: Magnus Karlsson @ 2019-12-17 13:27 UTC (permalink / raw)
To: Daniel Borkmann, kirill.shutemov, justin.he, catalin.marinas, linux-mm
Cc: syzbot, Andrii Nakryiko, Alexei Starovoitov,
Björn Töpel, bpf, David S. Miller, hawk,
Jakub Kicinski, John Fastabend, Jonathan Lemon, Martin KaFai Lau,
linux-kernel, Karlsson, Magnus, Network Development, Song Liu,
syzkaller-bugs, Yonghong Song
On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
>
> On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > syzbot has found a reproducer for the following crash on:
> > >
> > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > git tree: net-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> >
> > Bjorn / Magnus, given xsk below, PTAL, thanks!
>
> Thanks. I will take a look at it right away.
>
> /Magnus
After looking through the syzcaller report, I have the following
hypothesis that would dearly need some comments from MM-savy people
out there. Syzcaller creates, using mmap, a memory area that is
write-only and supplies this to a getsockopt call (in this case
XDP_STATISTICS, but probably does not matter really) as the area where
it wants the values to be stored. When the getsockopt implementation
gets to copy_to_user() to write out the values to user space, it
encounters a page fault when accessing this write-only page. When
servicing this, it gets to the following piece of code that triggers
the warning that syzcaller reports:
static inline bool cow_user_page(struct page *dst, struct page *src,
struct vm_fault *vmf)
{
....
snip
....
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
* zeroes.
*/
if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
/*
* Give a warn in case there can be some obscure
* use-case
*/
WARN_ON_ONCE(1);
clear_page(kaddr);
}
Before the following commit, it used to look like this:
commit 83d116c53058d505ddef051e90ab27f57015b025
Author: Jia He <justin.he@arm.com>
Date: Fri Oct 11 22:09:39 2019 +0800
mm: fix double page fault on arm64 if PTE_AF is cleared
static inline bool cow_user_page(struct page *dst, struct page *src,
struct vm_fault *vmf)
{
....
snip
....
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
* zeroes.
*/
if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
clear_page(kaddr);
So without a warning. My hypothesis is that if we create a page in the
same way as syzcaller then any getsockopt that does a copy_to_user()
(pretty much all of them I guess) will get this warning. I have not
tried this, so I might be wrong. If this is true, then the question is
what to do about it. One possible fix would be just to remove the
warning to get the same behavior as before. But it was probably put
there for a reason. Maybe some MM person could please comment on the
best way forward.
/Magnus
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 cow_user_page mm/memory.c:2229
> > > [inline]
> > > WARNING: CPU: 0 PID: 9104 at mm/memory.c:2229 wp_page_copy+0x10b7/0x1560
> > > mm/memory.c:2414
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 0 PID: 9104 Comm: syz-executor.0 Not tainted 5.5.0-rc1-syzkaller #0
> > > 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+0x197/0x210 lib/dump_stack.c:118
> > > panic+0x2e3/0x75c kernel/panic.c:221
> > > __warn.cold+0x2f/0x3e kernel/panic.c:582
> > > report_bug+0x289/0x300 lib/bug.c:195
> > > fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > > fixup_bug arch/x86/kernel/traps.c:169 [inline]
> > > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
> > > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
> > > invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
> > > RIP: 0010:cow_user_page mm/memory.c:2229 [inline]
> > > RIP: 0010:wp_page_copy+0x10b7/0x1560 mm/memory.c:2414
> > > Code: 4c 89 f7 ba 00 10 00 00 48 81 e6 00 f0 ff ff e8 0f e6 22 06 31 ff 41
> > > 89 c7 89 c6 e8 23 03 d3 ff 45 85 ff 74 0f e8 99 01 d3 ff <0f> 0b 4c 89 f7 e8
> > > 3f d8 22 06 e8 8a 01 d3 ff 65 4c 8b 34 25 c0 1e
> > > RSP: 0018:ffffc90002267668 EFLAGS: 00010293
> > > RAX: ffff8880a04c6140 RBX: ffffc90002267918 RCX: ffffffff81a22a0d
> > > RDX: 0000000000000000 RSI: ffffffff81a22a17 RDI: 0000000000000005
> > > RBP: ffffc900022677a8 R08: ffff8880a04c6140 R09: 0000000000000000
> > > R10: ffffed101125cfff R11: ffff8880892e7fff R12: ffff88809e403108
> > > R13: ffffea000224b9c0 R14: ffff8880892e7000 R15: 0000000000001000
> > > do_wp_page+0x543/0x1540 mm/memory.c:2724
> > > handle_pte_fault mm/memory.c:3961 [inline]
> > > __handle_mm_fault+0x327b/0x3da0 mm/memory.c:4075
> > > handle_mm_fault+0x3b2/0xa50 mm/memory.c:4112
> > > do_user_addr_fault arch/x86/mm/fault.c:1441 [inline]
> > > __do_page_fault+0x536/0xd80 arch/x86/mm/fault.c:1506
> > > do_page_fault+0x38/0x590 arch/x86/mm/fault.c:1530
> > > page_fault+0x39/0x40 arch/x86/entry/entry_64.S:1203
> > > RIP: 0010:copy_user_generic_unrolled+0x89/0xc0
> > > arch/x86/lib/copy_user_64.S:91
> > > Code: 38 4c 89 47 20 4c 89 4f 28 4c 89 57 30 4c 89 5f 38 48 8d 76 40 48 8d
> > > 7f 40 ff c9 75 b6 89 d1 83 e2 07 c1 e9 03 74 12 4c 8b 06 <4c> 89 07 48 8d 76
> > > 08 48 8d 7f 08 ff c9 75 ee 21 d2 74 10 89 d1 8a
> > > RSP: 0018:ffffc90002267bb8 EFLAGS: 00010206
> > > RAX: 0000000000000001 RBX: 0000000000000018 RCX: 0000000000000003
> > > RDX: 0000000000000000 RSI: ffffc90002267c58 RDI: 0000000020001300
> > > RBP: ffffc90002267bf0 R08: 0000000000000000 R09: fffff5200044cf8e
> > > R10: fffff5200044cf8d R11: ffffc90002267c6f R12: 0000000020001300
> > > R13: ffffc90002267c58 R14: 0000000020001318 R15: 00007ffffffff000
> > > copy_to_user include/linux/uaccess.h:152 [inline]
> > > xsk_getsockopt+0x575/0x6c0 net/xdp/xsk.c:898
> > > __sys_getsockopt+0x16d/0x310 net/socket.c:2174
> > > __do_sys_getsockopt net/socket.c:2189 [inline]
> > > __se_sys_getsockopt net/socket.c:2186 [inline]
> > > __x64_sys_getsockopt+0xbe/0x150 net/socket.c:2186
> > > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > RIP: 0033:0x45a909
> > > 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:00007f0ec9e9ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000000000045a909
> > > RDX: 0000000000000007 RSI: 000000000000011b RDI: 000000000000000a
> > > RBP: 000000000075bf20 R08: 0000000020000100 R09: 0000000000000000
> > > R10: 0000000020001300 R11: 0000000000000246 R12: 00007f0ec9e9f6d4
> > > R13: 00000000004c1ab5 R14: 00000000004d5f60 R15: 00000000ffffffff
> > > Kernel Offset: disabled
> > > Rebooting in 86400 seconds..
> > >
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-17 13:27 ` Magnus Karlsson
@ 2019-12-17 15:40 ` Catalin Marinas
2019-12-17 15:57 ` Magnus Karlsson
0 siblings, 1 reply; 11+ messages in thread
From: Catalin Marinas @ 2019-12-17 15:40 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Daniel Borkmann, kirill.shutemov, justin.he, linux-mm, syzbot,
Andrii Nakryiko, Alexei Starovoitov, Björn Töpel, bpf,
David S. Miller, hawk, Jakub Kicinski, John Fastabend,
Jonathan Lemon, Martin KaFai Lau, linux-kernel, Karlsson, Magnus,
Network Development, Song Liu, syzkaller-bugs, Yonghong Song
Hi Magnus,
Thanks for investigating this. I have more questions below rather than a
solution.
On Tue, Dec 17, 2019 at 02:27:22PM +0100, Magnus Karlsson wrote:
> On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
> <magnus.karlsson@gmail.com> wrote:
> > On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > >
> > > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > > syzbot has found a reproducer for the following crash on:
> > > >
> > > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > > git tree: net-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> > >
> > > Bjorn / Magnus, given xsk below, PTAL, thanks!
> >
> > Thanks. I will take a look at it right away.
> >
> > /Magnus
>
> After looking through the syzcaller report, I have the following
> hypothesis that would dearly need some comments from MM-savy people
> out there. Syzcaller creates, using mmap, a memory area that is
I guess that's not an anonymous mmap() since we don't seem to have a
struct page for src in cow_user_page() (the WARN_ON_ONCE path). Do you
have more information on the mmap() call?
> write-only and supplies this to a getsockopt call (in this case
> XDP_STATISTICS, but probably does not matter really) as the area where
> it wants the values to be stored. When the getsockopt implementation
> gets to copy_to_user() to write out the values to user space, it
> encounters a page fault when accessing this write-only page. When
> servicing this, it gets to the following piece of code that triggers
> the warning that syzcaller reports:
>
> static inline bool cow_user_page(struct page *dst, struct page *src,
> struct vm_fault *vmf)
> {
> ....
> snip
> ....
> /*
> * This really shouldn't fail, because the page is there
> * in the page tables. But it might just be unreadable,
> * in which case we just give up and fill the result with
> * zeroes.
> */
> if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> /*
> * Give a warn in case there can be some obscure
> * use-case
> */
> WARN_ON_ONCE(1);
> clear_page(kaddr);
> }
So on x86, a PROT_WRITE-only private page is mapped as non-readable? I
had the impression that write-only still allows reading by looking at
the __P010 definition.
Anyway, if it's not an anonymous mmap(), whoever handled the mapping may
have changed the permissions (e.g. some device).
> So without a warning. My hypothesis is that if we create a page in the
> same way as syzcaller then any getsockopt that does a copy_to_user()
> (pretty much all of them I guess) will get this warning.
The copy_to_user() only triggers the do_wp_page() fault handling. If
this is a CoW page (private read-only presumably, or at least not
writeable), the kernel tries to copy the original page given to
getsockopt into a new page and restart the copy_to_user(). Since the
kernel doesn't have a struct page for this (e.g. PFN mapping), it uses
__copy_from_user_inatomic() which fails because of the read permission.
> I have not tried this, so I might be wrong. If this is true, then the
> question is what to do about it. One possible fix would be just to
> remove the warning to get the same behavior as before. But it was
> probably put there for a reason.
It was there for some obscure cases, as the comment says ;). If the
above is a valid scenario that the user can trigger, we should probably
remove the WARN_ON.
--
Catalin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-17 15:40 ` Catalin Marinas
@ 2019-12-17 15:57 ` Magnus Karlsson
2019-12-17 22:38 ` Catalin Marinas
0 siblings, 1 reply; 11+ messages in thread
From: Magnus Karlsson @ 2019-12-17 15:57 UTC (permalink / raw)
To: Catalin Marinas
Cc: Daniel Borkmann, kirill.shutemov, justin.he, linux-mm, syzbot,
Andrii Nakryiko, Alexei Starovoitov, Björn Töpel, bpf,
David S. Miller, hawk, Jakub Kicinski, John Fastabend,
Jonathan Lemon, Martin KaFai Lau, linux-kernel, Karlsson, Magnus,
Network Development, Song Liu, syzkaller-bugs, Yonghong Song
On Tue, Dec 17, 2019 at 4:40 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Hi Magnus,
>
> Thanks for investigating this. I have more questions below rather than a
> solution.
>
> On Tue, Dec 17, 2019 at 02:27:22PM +0100, Magnus Karlsson wrote:
> > On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
> > <magnus.karlsson@gmail.com> wrote:
> > > On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > >
> > > > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > > > syzbot has found a reproducer for the following crash on:
> > > > >
> > > > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > > > git tree: net-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> > > >
> > > > Bjorn / Magnus, given xsk below, PTAL, thanks!
> > >
> > > Thanks. I will take a look at it right away.
> > >
> > > /Magnus
> >
> > After looking through the syzcaller report, I have the following
> > hypothesis that would dearly need some comments from MM-savy people
> > out there. Syzcaller creates, using mmap, a memory area that is
>
> I guess that's not an anonymous mmap() since we don't seem to have a
> struct page for src in cow_user_page() (the WARN_ON_ONCE path). Do you
> have more information on the mmap() call?
I have this from the syzcaller logs:
mmap(&(0x7f0000001000/0x2000)=nil, 0x2000, 0xfffffe, 0x12, r8, 0x0)
getsockopt$XDP_MMAP_OFFSETS(r8, 0x11b, 0x7, &(0x7f0000001300),
&(0x7f0000000100)=0x60)
The full log can be found at:
https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
Hope this helps.
> > write-only and supplies this to a getsockopt call (in this case
> > XDP_STATISTICS, but probably does not matter really) as the area where
> > it wants the values to be stored. When the getsockopt implementation
> > gets to copy_to_user() to write out the values to user space, it
> > encounters a page fault when accessing this write-only page. When
> > servicing this, it gets to the following piece of code that triggers
> > the warning that syzcaller reports:
> >
> > static inline bool cow_user_page(struct page *dst, struct page *src,
> > struct vm_fault *vmf)
> > {
> > ....
> > snip
> > ....
> > /*
> > * This really shouldn't fail, because the page is there
> > * in the page tables. But it might just be unreadable,
> > * in which case we just give up and fill the result with
> > * zeroes.
> > */
> > if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> > /*
> > * Give a warn in case there can be some obscure
> > * use-case
> > */
> > WARN_ON_ONCE(1);
> > clear_page(kaddr);
> > }
>
> So on x86, a PROT_WRITE-only private page is mapped as non-readable? I
> had the impression that write-only still allows reading by looking at
> the __P010 definition.
>
> Anyway, if it's not an anonymous mmap(), whoever handled the mapping may
> have changed the permissions (e.g. some device).
>
> > So without a warning. My hypothesis is that if we create a page in the
> > same way as syzcaller then any getsockopt that does a copy_to_user()
> > (pretty much all of them I guess) will get this warning.
>
> The copy_to_user() only triggers the do_wp_page() fault handling. If
> this is a CoW page (private read-only presumably, or at least not
> writeable), the kernel tries to copy the original page given to
> getsockopt into a new page and restart the copy_to_user(). Since the
> kernel doesn't have a struct page for this (e.g. PFN mapping), it uses
> __copy_from_user_inatomic() which fails because of the read permission.
>
> > I have not tried this, so I might be wrong. If this is true, then the
> > question is what to do about it. One possible fix would be just to
> > remove the warning to get the same behavior as before. But it was
> > probably put there for a reason.
>
> It was there for some obscure cases, as the comment says ;). If the
> above is a valid scenario that the user can trigger, we should probably
> remove the WARN_ON.
>
> --
> Catalin
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
[not found] <000000000000a6f2030598bbe38c@google.com>
2019-12-14 16:20 ` WARNING in wp_page_copy syzbot
@ 2019-12-17 20:16 ` syzbot
2020-03-24 2:47 ` syzbot
2 siblings, 0 replies; 11+ messages in thread
From: syzbot @ 2019-12-17 20:16 UTC (permalink / raw)
To: andriin, ast, bjorn.topel, bpf, catalin.marinas, daniel, davem,
hawk, jakub.kicinski, john.fastabend, jonathan.lemon, justin.he,
kafai, kirill.shutemov, linux-kernel, linux-mm, magnus.karlsson,
magnus.karlsson, netdev, songliubraving, syzkaller-bugs, yhs
syzbot has bisected this bug to:
commit 83d116c53058d505ddef051e90ab27f57015b025
Author: Jia He <justin.he@arm.com>
Date: Fri Oct 11 14:09:39 2019 +0000
mm: fix double page fault on arm64 if PTE_AF is cleared
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1378f5b6e00000
start commit: e31736d9 Merge tag 'nios2-v5.5-rc2' of git://git.kernel.or..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=10f8f5b6e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1778f5b6e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d
dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10fd9fb1e00000
Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
Fixes: 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is
cleared")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-17 15:57 ` Magnus Karlsson
@ 2019-12-17 22:38 ` Catalin Marinas
2019-12-18 15:00 ` Magnus Karlsson
2019-12-18 15:11 ` Kirill A. Shutemov
0 siblings, 2 replies; 11+ messages in thread
From: Catalin Marinas @ 2019-12-17 22:38 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Daniel Borkmann, kirill.shutemov, justin.he, linux-mm, syzbot,
Andrii Nakryiko, Alexei Starovoitov, Björn Töpel, bpf,
David S. Miller, hawk, Jakub Kicinski, John Fastabend,
Jonathan Lemon, Martin KaFai Lau, linux-kernel, Karlsson, Magnus,
Network Development, Song Liu, syzkaller-bugs, Yonghong Song
On Tue, Dec 17, 2019 at 04:57:34PM +0100, Magnus Karlsson wrote:
> On Tue, Dec 17, 2019 at 4:40 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Dec 17, 2019 at 02:27:22PM +0100, Magnus Karlsson wrote:
> > > On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
> > > <magnus.karlsson@gmail.com> wrote:
> > > > On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > > > > syzbot has found a reproducer for the following crash on:
> > > > > >
> > > > > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > > > > git tree: net-next
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > > > > >
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> > > > >
> > > > > Bjorn / Magnus, given xsk below, PTAL, thanks!
> > > >
> > > > Thanks. I will take a look at it right away.
> > > >
> > > > /Magnus
> > >
> > > After looking through the syzcaller report, I have the following
> > > hypothesis that would dearly need some comments from MM-savy people
> > > out there. Syzcaller creates, using mmap, a memory area that is
> >
> > I guess that's not an anonymous mmap() since we don't seem to have a
> > struct page for src in cow_user_page() (the WARN_ON_ONCE path). Do you
> > have more information on the mmap() call?
>
> I have this from the syzcaller logs:
>
> mmap(&(0x7f0000001000/0x2000)=nil, 0x2000, 0xfffffe, 0x12, r8, 0x0)
> getsockopt$XDP_MMAP_OFFSETS(r8, 0x11b, 0x7, &(0x7f0000001300),
> &(0x7f0000000100)=0x60)
>
> The full log can be found at:
> https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
Thanks. Prior to mmap, we have:
r8 = socket$xdp(0x2c, 0x3, 0x0)
So basically we have an mmap() on a socket descriptor with a subsequent
copy_to_user() writing this range. We do we even end up doing CoW on
such mapping? Maybe the socket code should also implement the .fault()
file op. It needs more digging.
--
Catalin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-17 22:38 ` Catalin Marinas
@ 2019-12-18 15:00 ` Magnus Karlsson
2019-12-18 15:11 ` Kirill A. Shutemov
1 sibling, 0 replies; 11+ messages in thread
From: Magnus Karlsson @ 2019-12-18 15:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: Daniel Borkmann, kirill.shutemov, justin.he, linux-mm, syzbot,
Andrii Nakryiko, Alexei Starovoitov, Björn Töpel, bpf,
David S. Miller, hawk, Jakub Kicinski, John Fastabend,
Jonathan Lemon, Martin KaFai Lau, linux-kernel, Karlsson, Magnus,
Network Development, Song Liu, syzkaller-bugs, Yonghong Song
On Tue, Dec 17, 2019 at 11:38 PM Catalin Marinas
<catalin.marinas@arm.com> wrote:
>
> On Tue, Dec 17, 2019 at 04:57:34PM +0100, Magnus Karlsson wrote:
> > On Tue, Dec 17, 2019 at 4:40 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Tue, Dec 17, 2019 at 02:27:22PM +0100, Magnus Karlsson wrote:
> > > > On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
> > > > <magnus.karlsson@gmail.com> wrote:
> > > > > On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > > > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > > > > > syzbot has found a reproducer for the following crash on:
> > > > > > >
> > > > > > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > > > > > git tree: net-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > > > > > >
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> > > > > >
> > > > > > Bjorn / Magnus, given xsk below, PTAL, thanks!
> > > > >
> > > > > Thanks. I will take a look at it right away.
> > > > >
> > > > > /Magnus
> > > >
> > > > After looking through the syzcaller report, I have the following
> > > > hypothesis that would dearly need some comments from MM-savy people
> > > > out there. Syzcaller creates, using mmap, a memory area that is
> > >
> > > I guess that's not an anonymous mmap() since we don't seem to have a
> > > struct page for src in cow_user_page() (the WARN_ON_ONCE path). Do you
> > > have more information on the mmap() call?
> >
> > I have this from the syzcaller logs:
> >
> > mmap(&(0x7f0000001000/0x2000)=nil, 0x2000, 0xfffffe, 0x12, r8, 0x0)
> > getsockopt$XDP_MMAP_OFFSETS(r8, 0x11b, 0x7, &(0x7f0000001300),
> > &(0x7f0000000100)=0x60)
> >
> > The full log can be found at:
> > https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
>
> Thanks. Prior to mmap, we have:
>
> r8 = socket$xdp(0x2c, 0x3, 0x0)
>
> So basically we have an mmap() on a socket descriptor with a subsequent
> copy_to_user() writing this range. We do we even end up doing CoW on
> such mapping? Maybe the socket code should also implement the .fault()
> file op. It needs more digging.
I am trying to reproduce it with syzkaller, but so far no luck on my
machine. Will keep you posted.
/Magnus
> --
> Catalin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
2019-12-17 22:38 ` Catalin Marinas
2019-12-18 15:00 ` Magnus Karlsson
@ 2019-12-18 15:11 ` Kirill A. Shutemov
1 sibling, 0 replies; 11+ messages in thread
From: Kirill A. Shutemov @ 2019-12-18 15:11 UTC (permalink / raw)
To: Catalin Marinas
Cc: Magnus Karlsson, Daniel Borkmann, kirill.shutemov, justin.he,
linux-mm, syzbot, Andrii Nakryiko, Alexei Starovoitov,
Björn Töpel, bpf, David S. Miller, hawk,
Jakub Kicinski, John Fastabend, Jonathan Lemon, Martin KaFai Lau,
linux-kernel, Karlsson, Magnus, Network Development, Song Liu,
syzkaller-bugs, Yonghong Song
On Tue, Dec 17, 2019 at 10:38:09PM +0000, Catalin Marinas wrote:
> On Tue, Dec 17, 2019 at 04:57:34PM +0100, Magnus Karlsson wrote:
> > On Tue, Dec 17, 2019 at 4:40 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Tue, Dec 17, 2019 at 02:27:22PM +0100, Magnus Karlsson wrote:
> > > > On Mon, Dec 16, 2019 at 4:10 PM Magnus Karlsson
> > > > <magnus.karlsson@gmail.com> wrote:
> > > > > On Mon, Dec 16, 2019 at 4:00 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > > > On Sat, Dec 14, 2019 at 08:20:07AM -0800, syzbot wrote:
> > > > > > > syzbot has found a reproducer for the following crash on:
> > > > > > >
> > > > > > > HEAD commit: 1d1997db Revert "nfp: abm: fix memory leak in nfp_abm_u32_..
> > > > > > > git tree: net-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1029f851e00000
> > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=cef1fd5032faee91
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
> > > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
> > > > > > >
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+9301f2f33873407d5b33@syzkaller.appspotmail.com
> > > > > >
> > > > > > Bjorn / Magnus, given xsk below, PTAL, thanks!
> > > > >
> > > > > Thanks. I will take a look at it right away.
> > > > >
> > > > > /Magnus
> > > >
> > > > After looking through the syzcaller report, I have the following
> > > > hypothesis that would dearly need some comments from MM-savy people
> > > > out there. Syzcaller creates, using mmap, a memory area that is
> > >
> > > I guess that's not an anonymous mmap() since we don't seem to have a
> > > struct page for src in cow_user_page() (the WARN_ON_ONCE path). Do you
> > > have more information on the mmap() call?
> >
> > I have this from the syzcaller logs:
> >
> > mmap(&(0x7f0000001000/0x2000)=nil, 0x2000, 0xfffffe, 0x12, r8, 0x0)
> > getsockopt$XDP_MMAP_OFFSETS(r8, 0x11b, 0x7, &(0x7f0000001300),
> > &(0x7f0000000100)=0x60)
> >
> > The full log can be found at:
> > https://syzkaller.appspot.com/x/repro.syz?x=119d9fb1e00000
>
> Thanks. Prior to mmap, we have:
>
> r8 = socket$xdp(0x2c, 0x3, 0x0)
>
> So basically we have an mmap() on a socket descriptor with a subsequent
> copy_to_user() writing this range. We do we even end up doing CoW on
> such mapping?
It's a non-readable private mapping of a socket. Any write to it would
cause CoW.
BTW, how useful memory mapped sockets are? I don't know much about
networking, but it looks like a rarely used feature that substantially
increase attack surface. CAP_NET_RAW is easy to come by nowadays with
user-ns.
Few years back I was able to modify zero page via memory mapped socket...
> Maybe the socket code should also implement the .fault()
> file op. It needs more digging.
Caller definitely does a weird thing here that doesn't suppose to produce
a meaningful result. I think we can keep the warning for now just to make
sure we don't have any more-or-less legitimate obscure use-case.
But ultimately this WARN_ON_ONCE() has to be upgraded to SIGSEGV or
SIGBUS. Pretending that we do anything meaningful here by clearing the
page unlikely does anything useful to a user.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: WARNING in wp_page_copy
[not found] <000000000000a6f2030598bbe38c@google.com>
2019-12-14 16:20 ` WARNING in wp_page_copy syzbot
2019-12-17 20:16 ` syzbot
@ 2020-03-24 2:47 ` syzbot
2 siblings, 0 replies; 11+ messages in thread
From: syzbot @ 2020-03-24 2:47 UTC (permalink / raw)
To: akpm, andriin, ast, bjorn.topel, bpf, catalin.marinas, daniel,
davem, hawk, jakub.kicinski, jmoyer, john.fastabend,
jonathan.lemon, justin.he, kafai, kirill.shutemov, kirill,
linux-kernel, linux-mm, magnus.karlsson, magnus.karlsson, netdev,
songliubraving, syzkaller-bugs, torvalds, yhs
syzbot suspects this bug was fixed by commit:
commit c3e5ea6ee574ae5e845a40ac8198de1fb63bb3ab
Author: Kirill A. Shutemov <kirill@shutemov.name>
Date: Fri Mar 6 06:28:32 2020 +0000
mm: avoid data corruption on CoW fault into PFN-mapped VMA
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1170c813e00000
start commit: e31736d9 Merge tag 'nios2-v5.5-rc2' of git://git.kernel.or..
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d
dashboard link: https://syzkaller.appspot.com/bug?extid=9301f2f33873407d5b33
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10fd9fb1e00000
If the result looks correct, please mark the bug fixed by replying with:
#syz fix: mm: avoid data corruption on CoW fault into PFN-mapped VMA
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-03-24 2:47 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <000000000000a6f2030598bbe38c@google.com>
2019-12-14 16:20 ` WARNING in wp_page_copy syzbot
2019-12-16 15:00 ` Daniel Borkmann
2019-12-16 15:10 ` Magnus Karlsson
2019-12-17 13:27 ` Magnus Karlsson
2019-12-17 15:40 ` Catalin Marinas
2019-12-17 15:57 ` Magnus Karlsson
2019-12-17 22:38 ` Catalin Marinas
2019-12-18 15:00 ` Magnus Karlsson
2019-12-18 15:11 ` Kirill A. Shutemov
2019-12-17 20:16 ` syzbot
2020-03-24 2:47 ` syzbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).