Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
* [syzbot] WARNING in unsafe_follow_pfn
@ 2021-03-30 15:26 syzbot
  2021-03-30 17:04 ` Paolo Bonzini
  0 siblings, 1 reply; 8+ messages in thread
From: syzbot @ 2021-03-30 15:26 UTC (permalink / raw)
  To: akpm, bp, daniel.vetter, daniel.vetter, hpa, jmattson, jmorris,
	joro, kvm, linux-kernel, linux-media, linux-mm,
	linux-security-module, m.szyprowski, mchehab, mingo, pbonzini,
	seanjc, serge, syzkaller-bugs, tfiga, tglx, vkuznets, wanpengli,
	x86

Hello,

syzbot found the following issue on:

HEAD commit:    93129492 Add linux-next specific files for 20210326
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000

The issue was bisected to:

commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Mar 16 15:33:01 2021 +0000

    mm: Add unsafe_follow_pfn

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+015dd7cdbbbc2c180c65@syzkaller.appspotmail.com
Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")

------------[ cut here ]------------
unsafe follow_pfn usage
WARNING: CPU: 1 PID: 8426 at mm/memory.c:4807 unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
Modules linked in:
CPU: 0 PID: 8426 Comm: syz-executor677 Not tainted 5.12.0-rc4-next-20210326-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
Code: 8b 7c 24 20 49 89 6d 00 e8 6e 84 64 07 e9 30 ff ff ff e8 f4 19 cb ff 48 c7 c7 40 1f 76 89 c6 05 56 eb 09 0c 01 e8 34 1a 21 07 <0f> 0b e9 71 fe ff ff 41 bc ea ff ff ff e9 06 ff ff ff e8 1a 65 0f
RSP: 0018:ffffc9000161f660 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 1ffff920002c3ecc RCX: 0000000000000000
RDX: ffff88801954d580 RSI: ffffffff815c3fd5 RDI: fffff520002c3ebe
RBP: ffff888023d56948 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815bd77e R11: 0000000000000000 R12: 0000000021000000
R13: ffff8880143a4010 R14: 0000000000000000 R15: 0000000000000110
FS:  00000000005d1300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172c4cd6c0 CR3: 0000000011f70000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 get_vaddr_frames+0x337/0x600 drivers/media/common/videobuf2/frame_vector.c:72
 vb2_create_framevec+0x55/0xc0 drivers/media/common/videobuf2/videobuf2-memops.c:50
 vb2_vmalloc_get_userptr+0xce/0x4c0 drivers/media/common/videobuf2/videobuf2-vmalloc.c:90
 __prepare_userptr+0x342/0x15f0 drivers/media/common/videobuf2/videobuf2-core.c:1128
 __buf_prepare+0x635/0x7d0 drivers/media/common/videobuf2/videobuf2-core.c:1367
 vb2_core_qbuf+0xa9d/0x11c0 drivers/media/common/videobuf2/videobuf2-core.c:1658
 vb2_qbuf+0x135/0x1a0 drivers/media/common/videobuf2/videobuf2-v4l2.c:820
 vb2_ioctl_qbuf+0xfb/0x140 drivers/media/common/videobuf2/videobuf2-v4l2.c:1050
 v4l_qbuf drivers/media/v4l2-core/v4l2-ioctl.c:2027 [inline]
 v4l_qbuf+0x92/0xc0 drivers/media/v4l2-core/v4l2-ioctl.c:2021
 __video_do_ioctl+0xb94/0xe20 drivers/media/v4l2-core/v4l2-ioctl.c:2951
 video_usercopy+0x253/0x1300 drivers/media/v4l2-core/v4l2-ioctl.c:3297
 v4l2_ioctl+0x1b3/0x250 drivers/media/v4l2-core/v4l2-dev.c:366
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x443639
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffee3065668 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000443639
RDX: 0000000020000140 RSI: 00000000c058560f RDI: 0000000000000004
RBP: 00000000004031e0 R08: 00000000004004a0 R09: 00000000004004a0
R10: 00236962762f7665 R11: 0000000000000246 R12: 0000000000403270
R13: 0000000000000000 R14: 00000000004b1018 R15: 00000000004004a0


---
This report 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 syzkaller@googlegroups.com.

syzbot will keep track of this issue. 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 issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-03-30 15:26 [syzbot] WARNING in unsafe_follow_pfn syzbot
@ 2021-03-30 17:04 ` Paolo Bonzini
  2021-03-31  4:29   ` Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Paolo Bonzini @ 2021-03-30 17:04 UTC (permalink / raw)
  To: syzbot, akpm, bp, daniel.vetter, daniel.vetter, hpa, jmattson,
	jmorris, joro, kvm, linux-kernel, linux-media, linux-mm,
	linux-security-module, m.szyprowski, mchehab, mingo, seanjc,
	serge, syzkaller-bugs, tfiga, tglx, vkuznets, wanpengli, x86

On 30/03/21 17:26, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    93129492 Add linux-next specific files for 20210326
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
> dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000
> 
> The issue was bisected to:
> 
> commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Tue Mar 16 15:33:01 2021 +0000
> 
>      mm: Add unsafe_follow_pfn
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+015dd7cdbbbc2c180c65@syzkaller.appspotmail.com
> Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")

This is basically intentional because get_vaddr_frames is broken, isn't 
it?  I think it needs to be ignored in syzkaller.

Paolo

> ------------[ cut here ]------------
> unsafe follow_pfn usage
> WARNING: CPU: 1 PID: 8426 at mm/memory.c:4807 unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
> Modules linked in:
> CPU: 0 PID: 8426 Comm: syz-executor677 Not tainted 5.12.0-rc4-next-20210326-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
> Code: 8b 7c 24 20 49 89 6d 00 e8 6e 84 64 07 e9 30 ff ff ff e8 f4 19 cb ff 48 c7 c7 40 1f 76 89 c6 05 56 eb 09 0c 01 e8 34 1a 21 07 <0f> 0b e9 71 fe ff ff 41 bc ea ff ff ff e9 06 ff ff ff e8 1a 65 0f
> RSP: 0018:ffffc9000161f660 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 1ffff920002c3ecc RCX: 0000000000000000
> RDX: ffff88801954d580 RSI: ffffffff815c3fd5 RDI: fffff520002c3ebe
> RBP: ffff888023d56948 R08: 0000000000000000 R09: 0000000000000000
> R10: ffffffff815bd77e R11: 0000000000000000 R12: 0000000021000000
> R13: ffff8880143a4010 R14: 0000000000000000 R15: 0000000000000110
> FS:  00000000005d1300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f172c4cd6c0 CR3: 0000000011f70000 CR4: 00000000001506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   get_vaddr_frames+0x337/0x600 drivers/media/common/videobuf2/frame_vector.c:72
>   vb2_create_framevec+0x55/0xc0 drivers/media/common/videobuf2/videobuf2-memops.c:50
>   vb2_vmalloc_get_userptr+0xce/0x4c0 drivers/media/common/videobuf2/videobuf2-vmalloc.c:90
>   __prepare_userptr+0x342/0x15f0 drivers/media/common/videobuf2/videobuf2-core.c:1128
>   __buf_prepare+0x635/0x7d0 drivers/media/common/videobuf2/videobuf2-core.c:1367
>   vb2_core_qbuf+0xa9d/0x11c0 drivers/media/common/videobuf2/videobuf2-core.c:1658
>   vb2_qbuf+0x135/0x1a0 drivers/media/common/videobuf2/videobuf2-v4l2.c:820
>   vb2_ioctl_qbuf+0xfb/0x140 drivers/media/common/videobuf2/videobuf2-v4l2.c:1050
>   v4l_qbuf drivers/media/v4l2-core/v4l2-ioctl.c:2027 [inline]
>   v4l_qbuf+0x92/0xc0 drivers/media/v4l2-core/v4l2-ioctl.c:2021
>   __video_do_ioctl+0xb94/0xe20 drivers/media/v4l2-core/v4l2-ioctl.c:2951
>   video_usercopy+0x253/0x1300 drivers/media/v4l2-core/v4l2-ioctl.c:3297
>   v4l2_ioctl+0x1b3/0x250 drivers/media/v4l2-core/v4l2-dev.c:366
>   vfs_ioctl fs/ioctl.c:48 [inline]
>   __do_sys_ioctl fs/ioctl.c:753 [inline]
>   __se_sys_ioctl fs/ioctl.c:739 [inline]
>   __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
>   do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
>   entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x443639
> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffee3065668 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000443639
> RDX: 0000000020000140 RSI: 00000000c058560f RDI: 0000000000000004
> RBP: 00000000004031e0 R08: 00000000004004a0 R09: 00000000004004a0
> R10: 00236962762f7665 R11: 0000000000000246 R12: 0000000000403270
> R13: 0000000000000000 R14: 00000000004b1018 R15: 00000000004004a0
> 
> 
> ---
> This report 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 syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. 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 issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-03-30 17:04 ` Paolo Bonzini
@ 2021-03-31  4:29   ` Dan Carpenter
  2021-04-01 12:19     ` Jason Gunthorpe
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2021-03-31  4:29 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: syzbot, akpm, bp, daniel.vetter, daniel.vetter, hpa, jmattson,
	jmorris, joro, kvm, linux-kernel, linux-media, linux-mm,
	linux-security-module, m.szyprowski, mchehab, mingo, seanjc,
	serge, syzkaller-bugs, tfiga, tglx, vkuznets, wanpengli, x86

On Tue, Mar 30, 2021 at 07:04:30PM +0200, Paolo Bonzini wrote:
> On 30/03/21 17:26, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    93129492 Add linux-next specific files for 20210326
> > git tree:       linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
> > dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000
> > 
> > The issue was bisected to:
> > 
> > commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date:   Tue Mar 16 15:33:01 2021 +0000
> > 
> >      mm: Add unsafe_follow_pfn
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+015dd7cdbbbc2c180c65@syzkaller.appspotmail.com
> > Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")
> 
> This is basically intentional because get_vaddr_frames is broken, isn't it?
> I think it needs to be ignored in syzkaller.

What?

The bisect is wrong (because it's blaming the commit which added the
warning instead of the commit which added the buggy caller) but the
warning is correct.

Plus users are going to be seeing this as well.  According to the commit
message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
there's some users where this is not fixable (like v4l userptr of iomem
mappings)".  It sort of seems crazy to dump this giant splat and then
tell users to ignore it forever because it can't be fixed...  0_0

regards,
dan carpenter

> 
> Paolo
> 
> > ------------[ cut here ]------------
> > unsafe follow_pfn usage
> > WARNING: CPU: 1 PID: 8426 at mm/memory.c:4807 unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
> > Modules linked in:
> > CPU: 0 PID: 8426 Comm: syz-executor677 Not tainted 5.12.0-rc4-next-20210326-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > RIP: 0010:unsafe_follow_pfn+0x20f/0x260 mm/memory.c:4807
> > Code: 8b 7c 24 20 49 89 6d 00 e8 6e 84 64 07 e9 30 ff ff ff e8 f4 19 cb ff 48 c7 c7 40 1f 76 89 c6 05 56 eb 09 0c 01 e8 34 1a 21 07 <0f> 0b e9 71 fe ff ff 41 bc ea ff ff ff e9 06 ff ff ff e8 1a 65 0f
> > RSP: 0018:ffffc9000161f660 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: 1ffff920002c3ecc RCX: 0000000000000000
> > RDX: ffff88801954d580 RSI: ffffffff815c3fd5 RDI: fffff520002c3ebe
> > RBP: ffff888023d56948 R08: 0000000000000000 R09: 0000000000000000
> > R10: ffffffff815bd77e R11: 0000000000000000 R12: 0000000021000000
> > R13: ffff8880143a4010 R14: 0000000000000000 R15: 0000000000000110
> > FS:  00000000005d1300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f172c4cd6c0 CR3: 0000000011f70000 CR4: 00000000001506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >   get_vaddr_frames+0x337/0x600 drivers/media/common/videobuf2/frame_vector.c:72
> >   vb2_create_framevec+0x55/0xc0 drivers/media/common/videobuf2/videobuf2-memops.c:50
> >   vb2_vmalloc_get_userptr+0xce/0x4c0 drivers/media/common/videobuf2/videobuf2-vmalloc.c:90
> >   __prepare_userptr+0x342/0x15f0 drivers/media/common/videobuf2/videobuf2-core.c:1128
> >   __buf_prepare+0x635/0x7d0 drivers/media/common/videobuf2/videobuf2-core.c:1367
> >   vb2_core_qbuf+0xa9d/0x11c0 drivers/media/common/videobuf2/videobuf2-core.c:1658
> >   vb2_qbuf+0x135/0x1a0 drivers/media/common/videobuf2/videobuf2-v4l2.c:820
> >   vb2_ioctl_qbuf+0xfb/0x140 drivers/media/common/videobuf2/videobuf2-v4l2.c:1050
> >   v4l_qbuf drivers/media/v4l2-core/v4l2-ioctl.c:2027 [inline]
> >   v4l_qbuf+0x92/0xc0 drivers/media/v4l2-core/v4l2-ioctl.c:2021
> >   __video_do_ioctl+0xb94/0xe20 drivers/media/v4l2-core/v4l2-ioctl.c:2951
> >   video_usercopy+0x253/0x1300 drivers/media/v4l2-core/v4l2-ioctl.c:3297
> >   v4l2_ioctl+0x1b3/0x250 drivers/media/v4l2-core/v4l2-dev.c:366
> >   vfs_ioctl fs/ioctl.c:48 [inline]
> >   __do_sys_ioctl fs/ioctl.c:753 [inline]
> >   __se_sys_ioctl fs/ioctl.c:739 [inline]
> >   __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
> >   do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >   entry_SYSCALL_64_after_hwframe+0x44/0xae
> > RIP: 0033:0x443639
> > Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007ffee3065668 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000443639
> > RDX: 0000000020000140 RSI: 00000000c058560f RDI: 0000000000000004
> > RBP: 00000000004031e0 R08: 00000000004004a0 R09: 00000000004004a0
> > R10: 00236962762f7665 R11: 0000000000000246 R12: 0000000000403270
> > R13: 0000000000000000 R14: 00000000004b1018 R15: 00000000004004a0
> > 
> > 
> > ---
> > This report 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 syzkaller@googlegroups.com.
> > 
> > syzbot will keep track of this issue. 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 issue, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> > 
> 
> -- 
> 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/2db3c803-6a94-9345-261a-a2bb74370c02%40redhat.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-03-31  4:29   ` Dan Carpenter
@ 2021-04-01 12:19     ` Jason Gunthorpe
  2021-04-13 17:20       ` Dmitry Vyukov
  0 siblings, 1 reply; 8+ messages in thread
From: Jason Gunthorpe @ 2021-04-01 12:19 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Paolo Bonzini, syzbot, akpm, bp, daniel.vetter, daniel.vetter,
	hpa, jmattson, jmorris, joro, kvm, linux-kernel, linux-media,
	linux-mm, linux-security-module, m.szyprowski, mchehab, mingo,
	seanjc, serge, syzkaller-bugs, tfiga, tglx, vkuznets, wanpengli,
	x86

On Wed, Mar 31, 2021 at 07:29:22AM +0300, Dan Carpenter wrote:
> On Tue, Mar 30, 2021 at 07:04:30PM +0200, Paolo Bonzini wrote:
> > On 30/03/21 17:26, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    93129492 Add linux-next specific files for 20210326
> > > git tree:       linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000
> > > 
> > > The issue was bisected to:
> > > 
> > > commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
> > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Date:   Tue Mar 16 15:33:01 2021 +0000
> > > 
> > >      mm: Add unsafe_follow_pfn
> > > 
> > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
> > > final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+015dd7cdbbbc2c180c65@syzkaller.appspotmail.com
> > > Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")
> > 
> > This is basically intentional because get_vaddr_frames is broken, isn't it?
> > I think it needs to be ignored in syzkaller.
> 
> What?
> 
> The bisect is wrong (because it's blaming the commit which added the
> warning instead of the commit which added the buggy caller) but the
> warning is correct.
> 
> Plus users are going to be seeing this as well.  According to the commit
> message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> there's some users where this is not fixable (like v4l userptr of iomem
> mappings)".  It sort of seems crazy to dump this giant splat and then
> tell users to ignore it forever because it can't be fixed...  0_0

I think the discussion conclusion was that this interface should not
be used by userspace anymore, it is obsolete by some new interface?

It should be protected by some kconfig and the kconfig should be
turned off for syzkaller runs.

Jason

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-04-01 12:19     ` Jason Gunthorpe
@ 2021-04-13 17:20       ` Dmitry Vyukov
  2021-04-13 18:11         ` Jason Gunthorpe
  0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Vyukov @ 2021-04-13 17:20 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Dan Carpenter, Paolo Bonzini, syzbot, Andrew Morton,
	Borislav Petkov, Daniel Vetter, daniel.vetter, H. Peter Anvin,
	Jim Mattson, James Morris, Joerg Roedel, KVM list, LKML,
	Linux Media Mailing List, Linux-MM, linux-security-module,
	m.szyprowski, Mauro Carvalho Chehab, Ingo Molnar,
	Sean Christopherson, Serge E. Hallyn, syzkaller-bugs,
	Tomasz Figa, Thomas Gleixner, Vitaly Kuznetsov, Wanpeng Li,
	the arch/x86 maintainers

On Thu, Apr 1, 2021 at 2:19 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Wed, Mar 31, 2021 at 07:29:22AM +0300, Dan Carpenter wrote:
> > On Tue, Mar 30, 2021 at 07:04:30PM +0200, Paolo Bonzini wrote:
> > > On 30/03/21 17:26, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    93129492 Add linux-next specific files for 20210326
> > > > git tree:       linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000
> > > >
> > > > The issue was bisected to:
> > > >
> > > > commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
> > > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > Date:   Tue Mar 16 15:33:01 2021 +0000
> > > >
> > > >      mm: Add unsafe_follow_pfn
> > > >
> > > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
> > > > final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+015dd7cdbbbc2c180c65@syzkaller.appspotmail.com
> > > > Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")
> > >
> > > This is basically intentional because get_vaddr_frames is broken, isn't it?
> > > I think it needs to be ignored in syzkaller.
> >
> > What?
> >
> > The bisect is wrong (because it's blaming the commit which added the
> > warning instead of the commit which added the buggy caller) but the
> > warning is correct.
> >
> > Plus users are going to be seeing this as well.  According to the commit
> > message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> > there's some users where this is not fixable (like v4l userptr of iomem
> > mappings)".  It sort of seems crazy to dump this giant splat and then
> > tell users to ignore it forever because it can't be fixed...  0_0
>
> I think the discussion conclusion was that this interface should not
> be used by userspace anymore, it is obsolete by some new interface?
>
> It should be protected by some kconfig and the kconfig should be
> turned off for syzkaller runs.

If this is not a kernel bug, then it must not use WARN_ON[_ONCE]. It
makes the kernel untestable for both automated systems and humans:

https://lwn.net/Articles/769365/

<quote>
Greg Kroah-Hartman raised the problem of core kernel API code that
will use WARN_ON_ONCE() to complain about bad usage; that will not
generate the desired result if WARN_ON_ONCE() is configured to crash
the machine. He was told that the code should just call pr_warn()
instead, and that the called function should return an error in such
situations. It was generally agreed that any WARN_ON() or
WARN_ON_ONCE() calls that can be triggered from user space need to be
fixed.
</quote>


https://lore.kernel.org/netdev/20210413085522.2caee809@gandalf.local.home/
From: Steven Rostedt
<quote>

I agree. WARN_ON(_ONCE) should be reserved for anomalies that should not
happen ever. Anything that the user could trigger, should not trigger a
WARN_ON.

A WARN_ON is perfectly fine for detecting an accounting error inside the
kernel. I have them scattered all over my code, but they should never be
hit, even if something in user space tries to hit it. (with an exception of
an interface I want to deprecate, where I want to know if it's still being
used ;-) Of course, that wouldn't help bots testing the code. And I haven't
done that in years)

Any anomaly that can be triggered by user space doing something it should
not be doing really needs a pr_warn().
</quote>

And if it's a kernel bug reachable from user-space, then I think this
code should be removed entirely, not just on all testing systems. Or
otherwise if we are not removing it for some reason, then it needs to
be fixed.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-04-13 17:20       ` Dmitry Vyukov
@ 2021-04-13 18:11         ` Jason Gunthorpe
  2021-04-13 18:27           ` Dmitry Vyukov
  2021-04-14  4:37           ` Dan Carpenter
  0 siblings, 2 replies; 8+ messages in thread
From: Jason Gunthorpe @ 2021-04-13 18:11 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Dan Carpenter, Paolo Bonzini, syzbot, Andrew Morton,
	Borislav Petkov, Daniel Vetter, daniel.vetter, H. Peter Anvin,
	Jim Mattson, James Morris, Joerg Roedel, KVM list, LKML,
	Linux Media Mailing List, Linux-MM, linux-security-module,
	m.szyprowski, Mauro Carvalho Chehab, Ingo Molnar,
	Sean Christopherson, Serge E. Hallyn, syzkaller-bugs,
	Tomasz Figa, Thomas Gleixner, Vitaly Kuznetsov, Wanpeng Li,
	the arch/x86 maintainers

On Tue, Apr 13, 2021 at 07:20:12PM +0200, Dmitry Vyukov wrote:
> > > Plus users are going to be seeing this as well.  According to the commit
> > > message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> > > there's some users where this is not fixable (like v4l userptr of iomem
> > > mappings)".  It sort of seems crazy to dump this giant splat and then
> > > tell users to ignore it forever because it can't be fixed...  0_0
> >
> > I think the discussion conclusion was that this interface should not
> > be used by userspace anymore, it is obsolete by some new interface?
> >
> > It should be protected by some kconfig and the kconfig should be
> > turned off for syzkaller runs.
> 
> If this is not a kernel bug, then it must not use WARN_ON[_ONCE]. It
> makes the kernel untestable for both automated systems and humans:

It is a kernel security bug triggerable by userspace.

> And if it's a kernel bug reachable from user-space, then I think this
> code should be removed entirely, not just on all testing systems. Or
> otherwise if we are not removing it for some reason, then it needs to
> be fixed.

Legacy embedded systems apparently require it.

It should be blocked by a kconfig. Distributions and syzkaller runs
should not enable that kconfig. What else can we do for insane uapi?

Jason

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-04-13 18:11         ` Jason Gunthorpe
@ 2021-04-13 18:27           ` Dmitry Vyukov
  2021-04-14  4:37           ` Dan Carpenter
  1 sibling, 0 replies; 8+ messages in thread
From: Dmitry Vyukov @ 2021-04-13 18:27 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Dan Carpenter, Paolo Bonzini, syzbot, Andrew Morton,
	Borislav Petkov, Daniel Vetter, daniel.vetter, H. Peter Anvin,
	Jim Mattson, James Morris, Joerg Roedel, KVM list, LKML,
	Linux Media Mailing List, Linux-MM, linux-security-module,
	m.szyprowski, Mauro Carvalho Chehab, Ingo Molnar,
	Sean Christopherson, Serge E. Hallyn, syzkaller-bugs,
	Tomasz Figa, Thomas Gleixner, Vitaly Kuznetsov, Wanpeng Li,
	the arch/x86 maintainers

On Tue, Apr 13, 2021 at 8:11 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Tue, Apr 13, 2021 at 07:20:12PM +0200, Dmitry Vyukov wrote:
> > > > Plus users are going to be seeing this as well.  According to the commit
> > > > message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> > > > there's some users where this is not fixable (like v4l userptr of iomem
> > > > mappings)".  It sort of seems crazy to dump this giant splat and then
> > > > tell users to ignore it forever because it can't be fixed...  0_0
> > >
> > > I think the discussion conclusion was that this interface should not
> > > be used by userspace anymore, it is obsolete by some new interface?
> > >
> > > It should be protected by some kconfig and the kconfig should be
> > > turned off for syzkaller runs.
> >
> > If this is not a kernel bug, then it must not use WARN_ON[_ONCE]. It
> > makes the kernel untestable for both automated systems and humans:
>
> It is a kernel security bug triggerable by userspace.
>
> > And if it's a kernel bug reachable from user-space, then I think this
> > code should be removed entirely, not just on all testing systems. Or
> > otherwise if we are not removing it for some reason, then it needs to
> > be fixed.
>
> Legacy embedded systems apparently require it.
>
> It should be blocked by a kconfig. Distributions and syzkaller runs
> should not enable that kconfig. What else can we do for insane uapi?

I see. Adding a config gives at least some path forward, so if there
are no better options, that's do that. If we default it to 'n' and add
a bold warning in the description, it may work.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [syzbot] WARNING in unsafe_follow_pfn
  2021-04-13 18:11         ` Jason Gunthorpe
  2021-04-13 18:27           ` Dmitry Vyukov
@ 2021-04-14  4:37           ` Dan Carpenter
  1 sibling, 0 replies; 8+ messages in thread
From: Dan Carpenter @ 2021-04-14  4:37 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Dmitry Vyukov, Paolo Bonzini, syzbot, Andrew Morton,
	Borislav Petkov, Daniel Vetter, daniel.vetter, H. Peter Anvin,
	Jim Mattson, James Morris, Joerg Roedel, KVM list, LKML,
	Linux Media Mailing List, Linux-MM, linux-security-module,
	m.szyprowski, Mauro Carvalho Chehab, Ingo Molnar,
	Sean Christopherson, Serge E. Hallyn, syzkaller-bugs,
	Tomasz Figa, Thomas Gleixner, Vitaly Kuznetsov, Wanpeng Li,
	the arch/x86 maintainers

On Tue, Apr 13, 2021 at 03:11:45PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 13, 2021 at 07:20:12PM +0200, Dmitry Vyukov wrote:
> > > > Plus users are going to be seeing this as well.  According to the commit
> > > > message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> > > > there's some users where this is not fixable (like v4l userptr of iomem
> > > > mappings)".  It sort of seems crazy to dump this giant splat and then
> > > > tell users to ignore it forever because it can't be fixed...  0_0
> > >
> > > I think the discussion conclusion was that this interface should not
> > > be used by userspace anymore, it is obsolete by some new interface?
> > >
> > > It should be protected by some kconfig and the kconfig should be
> > > turned off for syzkaller runs.
> > 
> > If this is not a kernel bug, then it must not use WARN_ON[_ONCE]. It
> > makes the kernel untestable for both automated systems and humans:
> 
> It is a kernel security bug triggerable by userspace.
> 
> > And if it's a kernel bug reachable from user-space, then I think this
> > code should be removed entirely, not just on all testing systems. Or
> > otherwise if we are not removing it for some reason, then it needs to
> > be fixed.
> 
> Legacy embedded systems apparently require it.

Are legacy embedded systems ever going to update their kernel?  It might
be better to just remove it.  (I don't really have any details outside
of your email so I don't know).

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-30 15:26 [syzbot] WARNING in unsafe_follow_pfn syzbot
2021-03-30 17:04 ` Paolo Bonzini
2021-03-31  4:29   ` Dan Carpenter
2021-04-01 12:19     ` Jason Gunthorpe
2021-04-13 17:20       ` Dmitry Vyukov
2021-04-13 18:11         ` Jason Gunthorpe
2021-04-13 18:27           ` Dmitry Vyukov
2021-04-14  4:37           ` Dan Carpenter

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git