general protection fault in send_sigurg_to_task

general protection fault in send_sigurg_to_task

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c2a63c400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab
dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 19114 Comm: syz-executor6 Not tainted 4.18.0-next-20180813+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06  
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0018:ffff88019afc74a8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88019afc7518 RCX: ffffc9000643f000
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff88019afc7540 R08: ffff8801b16ae5c0 R09: ffffed003b6046d6
R10: ffffed003b6046d6 R11: ffff8801db0236b3 R12: 1ffff100335f8e97
R13: ffff8801cb8ddb48 R14: 0000000000000001 R15: 0000000000000000
FS:  00007f2e92a99700(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4f3c16e18 CR3: 00000001b2e21000 CR4: 00000000001406f0
Call Trace:
  send_sigurg+0x342/0x480 fs/fcntl.c:833
  sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731
  tcp_check_urg net/ipv4/tcp_input.c:5266 [inline]
  tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307
  tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637
  tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532
  sk_backlog_rcv include/net/sock.h:931 [inline]
  __release_sock+0x12f/0x3a0 net/core/sock.c:2336
  release_sock+0xad/0x2c0 net/core/sock.c:2849
  tcp_sendmsg+0x3a/0x50 net/ipv4/tcp.c:1444
  inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
  sock_sendmsg_nosec net/socket.c:622 [inline]
  sock_sendmsg+0xd5/0x120 net/socket.c:632
  __sys_sendto+0x3d7/0x670 net/socket.c:1787
  __do_sys_sendto net/socket.c:1799 [inline]
  __se_sys_sendto net/socket.c:1795 [inline]
  __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1795
  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 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 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2e92a98c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f2e92a996d4 RCX: 0000000000457089
RDX: fffffffffffffd43 RSI: 0000000020de1fff RDI: 0000000000000004
RBP: 00000000009300a0 R08: 0000000020db4ff0 R09: 0000000000000010
R10: 0000000020008005 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3d08 R14: 00000000004c898d R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
    (ftrace buffer empty)
---[ end trace dc729739ab19eafd ]---
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06  
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0018:ffff88019afc74a8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88019afc7518 RCX: ffffc9000643f000
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff88019afc7540 R08: ffff8801b16ae5c0 R09: ffffed003b6046d6
R10: ffffed003b6046d6 R11: ffff8801db0236b3 R12: 1ffff100335f8e97
R13: ffff8801cb8ddb48 R14: 0000000000000001 R15: 0000000000000000
FS:  00007f2e92a99700(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4f3c16e18 CR3: 00000001b2e21000 CR4: 00000000001406f0


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

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

Re: general protection fault in send_sigurg_to_task

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab
dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15084b72400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com

nf_conntrack: default automatic helper assignment has been turned off for  
security reasons and CT-based  firewall rule not found. Use the iptables CT  
target to attach helpers instead.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06  
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0
Call Trace:
  <IRQ>
  send_sigurg+0x342/0x480 fs/fcntl.c:833
  sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731
  tcp_check_urg net/ipv4/tcp_input.c:5266 [inline]
  tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307
  tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637
  tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532
  tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824
  ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215
  NF_HOOK include/linux/netfilter.h:287 [inline]
  ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
  dst_input include/net/dst.h:450 [inline]
  ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
  NF_HOOK include/linux/netfilter.h:287 [inline]
  ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524
  __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
  process_backlog+0x219/0x760 net/core/dev.c:5808
  napi_poll net/core/dev.c:6228 [inline]
  net_rx_action+0x799/0x1900 net/core/dev.c:6294
  __do_softirq+0x2e8/0xa6d kernel/softirq.c:292
  invoke_softirq kernel/softirq.c:372 [inline]
  irq_exit+0x1d4/0x210 kernel/softirq.c:412
  exiting_irq arch/x86/include/asm/apic.h:527 [inline]
  smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055
  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867
  </IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783  
[inline]
RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941
Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 80 3c  
02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> 1f 44 00 00  
48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4
RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000
RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286
RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6
R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640
R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000
  lock_is_held include/linux/lockdep.h:344 [inline]
  rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285
  xa_entry include/linux/xarray.h:486 [inline]
  xas_next_entry include/linux/xarray.h:905 [inline]
  filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536
  do_fault_around mm/memory.c:3603 [inline]
  do_read_fault mm/memory.c:3637 [inline]
  do_fault mm/memory.c:3742 [inline]
  handle_pte_fault mm/memory.c:3973 [inline]
  __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097
  handle_mm_fault+0x53e/0xc80 mm/memory.c:4134
  __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395
  do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470
  page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164
RIP: 0033:0x400bc3
Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 83 c4  
10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89> c3 89 c5 85  
c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85
RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a
RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011
RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880
R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7
R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
    (ftrace buffer empty)
---[ end trace b74ebc04d71b9f0f ]---
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06  
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0

Re: general protection fault in send_sigurg_to_task

[J. Bruce Fields]

On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
> 
> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
> git tree:       linux-next

I fetched linux-next but don't have 5ed5da74de9e.

I'm also not sure why I'm on the cc for this.

--b.

> console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab
> dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15084b72400000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com
> 
> nf_conntrack: default automatic helper assignment has been turned
> off for security reasons and CT-based  firewall rule not found. Use
> the iptables CT target to attach helpers instead.
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf
> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
> FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0
> Call Trace:
>  <IRQ>
>  send_sigurg+0x342/0x480 fs/fcntl.c:833
>  sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731
>  tcp_check_urg net/ipv4/tcp_input.c:5266 [inline]
>  tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307
>  tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637
>  tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532
>  tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824
>  ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215
>  NF_HOOK include/linux/netfilter.h:287 [inline]
>  ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
>  dst_input include/net/dst.h:450 [inline]
>  ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
>  NF_HOOK include/linux/netfilter.h:287 [inline]
>  ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524
>  __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
>  process_backlog+0x219/0x760 net/core/dev.c:5808
>  napi_poll net/core/dev.c:6228 [inline]
>  net_rx_action+0x799/0x1900 net/core/dev.c:6294
>  __do_softirq+0x2e8/0xa6d kernel/softirq.c:292
>  invoke_softirq kernel/softirq.c:372 [inline]
>  irq_exit+0x1d4/0x210 kernel/softirq.c:412
>  exiting_irq arch/x86/include/asm/apic.h:527 [inline]
>  smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867
>  </IRQ>
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783
> [inline]
> RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941
> Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03
> 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f>
> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4
> RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000
> RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286
> RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6
> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640
> R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000
>  lock_is_held include/linux/lockdep.h:344 [inline]
>  rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285
>  xa_entry include/linux/xarray.h:486 [inline]
>  xas_next_entry include/linux/xarray.h:905 [inline]
>  filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536
>  do_fault_around mm/memory.c:3603 [inline]
>  do_read_fault mm/memory.c:3637 [inline]
>  do_fault mm/memory.c:3742 [inline]
>  handle_pte_fault mm/memory.c:3973 [inline]
>  __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097
>  handle_mm_fault+0x53e/0xc80 mm/memory.c:4134
>  __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395
>  do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470
>  page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164
> RIP: 0033:0x400bc3
> Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48
> 83 c4 10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89>
> c3 89 c5 85 c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85
> RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a
> RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011
> RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880
> R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7
> R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in:
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> ---[ end trace b74ebc04d71b9f0f ]---
> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf
> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
> FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0

Re: general protection fault in send_sigurg_to_task

[Dmitry Vyukov]

On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>> syzbot has found a reproducer for the following crash on:
>>
>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>> git tree:       linux-next
>
> I fetched linux-next but don't have 5ed5da74de9e.

Hi Bruce,

+Stephen for the disappeared linux-next commit.

On the dashboard link you can see that it also happened on a more
recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
now in linux-next.

> I'm also not sure why I'm on the cc for this.

You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
as maintainer of the file, which is the file where the crash happened.

> --b.
>
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab
>> dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15084b72400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com
>>
>> nf_conntrack: default automatic helper assignment has been turned
>> off for security reasons and CT-based  firewall rule not found. Use
>> the iptables CT target to attach helpers instead.
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
>> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
>> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
>> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf
>> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
>> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
>> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
>> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
>> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
>> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
>> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
>> FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0
>> Call Trace:
>>  <IRQ>
>>  send_sigurg+0x342/0x480 fs/fcntl.c:833
>>  sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731
>>  tcp_check_urg net/ipv4/tcp_input.c:5266 [inline]
>>  tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307
>>  tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637
>>  tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532
>>  tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824
>>  ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215
>>  NF_HOOK include/linux/netfilter.h:287 [inline]
>>  ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
>>  dst_input include/net/dst.h:450 [inline]
>>  ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
>>  NF_HOOK include/linux/netfilter.h:287 [inline]
>>  ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524
>>  __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
>>  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
>>  process_backlog+0x219/0x760 net/core/dev.c:5808
>>  napi_poll net/core/dev.c:6228 [inline]
>>  net_rx_action+0x799/0x1900 net/core/dev.c:6294
>>  __do_softirq+0x2e8/0xa6d kernel/softirq.c:292
>>  invoke_softirq kernel/softirq.c:372 [inline]
>>  irq_exit+0x1d4/0x210 kernel/softirq.c:412
>>  exiting_irq arch/x86/include/asm/apic.h:527 [inline]
>>  smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055
>>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867
>>  </IRQ>
>> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783
>> [inline]
>> RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941
>> Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03
>> 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f>
>> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4
>> RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
>> RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000
>> RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286
>> RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6
>> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640
>> R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000
>>  lock_is_held include/linux/lockdep.h:344 [inline]
>>  rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285
>>  xa_entry include/linux/xarray.h:486 [inline]
>>  xas_next_entry include/linux/xarray.h:905 [inline]
>>  filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536
>>  do_fault_around mm/memory.c:3603 [inline]
>>  do_read_fault mm/memory.c:3637 [inline]
>>  do_fault mm/memory.c:3742 [inline]
>>  handle_pte_fault mm/memory.c:3973 [inline]
>>  __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097
>>  handle_mm_fault+0x53e/0xc80 mm/memory.c:4134
>>  __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395
>>  do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470
>>  page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164
>> RIP: 0033:0x400bc3
>> Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48
>> 83 c4 10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89>
>> c3 89 c5 85 c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85
>> RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a
>> RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011
>> RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880
>> R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7
>> R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000
>> Modules linked in:
>> Dumping ftrace buffer:
>>    (ftrace buffer empty)
>> ---[ end trace b74ebc04d71b9f0f ]---
>> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
>> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
>> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
>> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf
>> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
>> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202
>> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0
>> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
>> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6
>> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85
>> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000
>> FS:  0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0

Re: general protection fault in send_sigurg_to_task

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Hi Bruce,

On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:  
> >> syzbot has found a reproducer for the following crash on:
> >>
> >> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
> >> git tree:       linux-next  
> >
> > I fetched linux-next but don't have 5ed5da74de9e.  
> 
> +Stephen for the disappeared linux-next commit.

That is just the HEAD commit on linux-next that day.  If you fetched
linux-next after I released next-20180814 yesterday, then it would have
a different HEAD commit.  If you check out the tag next-20180813, you
will get the above HEAD commit.

> On the dashboard link you can see that it also happened on a more
> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
> now in linux-next.

Which is just the HEAD commit of next-20180814.

Linux-next is rebuilt every day based on Linus' tree of the day,
followed by merging all the other branches, so its HEAD is different
every day.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: general protection fault in send_sigurg_to_task

[J. Bruce Fields]

On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote:
> Hi Bruce,
> 
> On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:  
> > >> syzbot has found a reproducer for the following crash on:
> > >>
> > >> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
> > >> git tree:       linux-next  
> > >
> > > I fetched linux-next but don't have 5ed5da74de9e.  
> > 
> > +Stephen for the disappeared linux-next commit.
> 
> That is just the HEAD commit on linux-next that day.  If you fetched
> linux-next after I released next-20180814 yesterday, then it would have
> a different HEAD commit.  If you check out the tag next-20180813, you
> will get the above HEAD commit.
> 
> > On the dashboard link you can see that it also happened on a more
> > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
> > now in linux-next.
> 
> Which is just the HEAD commit of next-20180814.
> 
> Linux-next is rebuilt every day based on Linus' tree of the day,
> followed by merging all the other branches, so its HEAD is different
> every day.

I new it was rebuilt every day, but for some reason I expected git to
fetch all new tags.  But that's wrong, it just fetches whatever
branch(es) you request and then only tags that happen to reference stuff
on that branch; from git-fetch(1): "By default, any tag that points into
the histories being fetched is also fetched; the effect is to fetch tags
that point at branches that you are interested in. This default behavior
can be changed by using the --tags or --no-tags options or by
configuring remote.<name>.tagOpt.  By using a refspec that fetches tags
explicitly, you can fetch tags that do not point into branches you are
interested in as well."

Sorry for the confusion!

--b.

Re: general protection fault in send_sigurg_to_task

[J. Bruce Fields]

On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote:
> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >> syzbot has found a reproducer for the following crash on:
> >>
> >> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
> >> git tree:       linux-next
> >
> > I fetched linux-next but don't have 5ed5da74de9e.
> 
> Hi Bruce,
> 
> +Stephen for the disappeared linux-next commit.
> 
> On the dashboard link you can see that it also happened on a more
> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
> now in linux-next.
> 
> > I'm also not sure why I'm on the cc for this.
> 
> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
> as maintainer of the file, which is the file where the crash happened.

We should probably fix that.  There's a tiny bit of lock-related code in
that file but it's not at all interesting compared, say, to the code
that this bug is hitting....

(Which I have no clue about.  send_sigurg_to_task() is getting a bad
task?  Help.)

--b.

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff51b5f..a5dca2be8513 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5541,9 +5541,6 @@ M:	Jeff Layton <jlayton@kernel.org>
 M:	"J. Bruce Fields" <bfields@fieldses.org>
 L:	linux-fsdevel@vger.kernel.org
 S:	Maintained
-F:	include/linux/fcntl.h
-F:	include/uapi/linux/fcntl.h
-F:	fs/fcntl.c
 F:	fs/locks.c
 
 FILESYSTEMS (VFS and infrastructure)

Re: general protection fault in send_sigurg_to_task

[Eric W. Biederman]

Dmitry Vyukov <dvyukov@google.com> writes:

> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>> syzbot has found a reproducer for the following crash on:
>>>
>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>>> git tree:       linux-next
>>
>> I fetched linux-next but don't have 5ed5da74de9e.
>
> Hi Bruce,
>
> +Stephen for the disappeared linux-next commit.
>
> On the dashboard link you can see that it also happened on a more
> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
> now in linux-next.
>
>> I'm also not sure why I'm on the cc for this.
>
> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
> as maintainer of the file, which is the file where the crash happened.

You need to use your reproducer to bisect and find the commit that
caused this.  Otherwise you will continue to confuse people.

get_maintainer.pl is not a good target for automated reporting
especially against linux-next.

Eric

Re: general protection fault in send_sigurg_to_task

[Dmitry Vyukov]

On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Dmitry Vyukov <dvyukov@google.com> writes:
>
>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>>> syzbot has found a reproducer for the following crash on:
>>>>
>>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>>>> git tree:       linux-next
>>>
>>> I fetched linux-next but don't have 5ed5da74de9e.
>>
>> Hi Bruce,
>>
>> +Stephen for the disappeared linux-next commit.
>>
>> On the dashboard link you can see that it also happened on a more
>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
>> now in linux-next.
>>
>>> I'm also not sure why I'm on the cc for this.
>>
>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
>> as maintainer of the file, which is the file where the crash happened.
>
> You need to use your reproducer to bisect and find the commit that
> caused this.  Otherwise you will continue to confuse people.
>
> get_maintainer.pl is not a good target for automated reporting
> especially against linux-next.

Hi Eric,

We will do bisection.
But I afraid it will not give perfect attribution for a number of reasons:
 - broken build/boot which happens sometimes for prolonged periods and
prohibits bisection
 - elusive races that can't be reproduced reliably and thus bisection
can give wrong results
 - bugs introduced too long ago (e.g. author email is not even valid today)
 - reproducers triggering more than 1 bug, so base bisection commit
can actually be for another bug, or bisection can switch from one bug
to another
 - last but not least, bugs without reproducers
Bisection will add useful information to the bug report, but it will
not necessary make attribution better than it is now.

Do you have more examples where bugs were misreported? From what I see
current attrition works well. There are episodic fallouts, but well,
nothing is perfect in this world. Humans don't bisect frequently and
misreport sometimes. I think we just need to re-route bugs in such
cases.

Re: general protection fault in send_sigurg_to_task

[Eric W. Biederman]

Dmitry Vyukov <dvyukov@google.com> writes:

> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Dmitry Vyukov <dvyukov@google.com> writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>>>> syzbot has found a reproducer for the following crash on:
>>>>>
>>>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>>>>> git tree:       linux-next
>>>>
>>>> I fetched linux-next but don't have 5ed5da74de9e.
>>>
>>> Hi Bruce,
>>>
>>> +Stephen for the disappeared linux-next commit.
>>>
>>> On the dashboard link you can see that it also happened on a more
>>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
>>> now in linux-next.
>>>
>>>> I'm also not sure why I'm on the cc for this.
>>>
>>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
>>> as maintainer of the file, which is the file where the crash happened.
>>
>> You need to use your reproducer to bisect and find the commit that
>> caused this.  Otherwise you will continue to confuse people.
>>
>> get_maintainer.pl is not a good target for automated reporting
>> especially against linux-next.
>
> Hi Eric,
>
> We will do bisection.
> But I afraid it will not give perfect attribution for a number of reasons:
>  - broken build/boot which happens sometimes for prolonged periods and
> prohibits bisection
>  - elusive races that can't be reproduced reliably and thus bisection
> can give wrong results
>  - bugs introduced too long ago (e.g. author email is not even valid today)
>  - reproducers triggering more than 1 bug, so base bisection commit
> can actually be for another bug, or bisection can switch from one bug
> to another
>  - last but not least, bugs without reproducers
> Bisection will add useful information to the bug report, but it will
> not necessary make attribution better than it is now.
>
> Do you have more examples where bugs were misreported? From what I see
> current attrition works well. There are episodic fallouts, but well,
> nothing is perfect in this world. Humans don't bisect frequently and
> misreport sometimes. I think we just need to re-route bugs in such
> cases.

I have yet to see syzbot make a good report.  Especially against
linux-next.

Eric

Re: general protection fault in send_sigurg_to_task

[J. Bruce Fields]

On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov <dvyukov@google.com> writes:
> 
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > <ebiederm@xmission.com> wrote:
> >> Dmitry Vyukov <dvyukov@google.com> writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> >>>>> syzbot has found a reproducer for the following crash on:
> >>>>>
> >>>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
> >>>>> git tree:       linux-next
> >>>>
> >>>> I fetched linux-next but don't have 5ed5da74de9e.
> >>>
> >>> Hi Bruce,
> >>>
> >>> +Stephen for the disappeared linux-next commit.
> >>>
> >>> On the dashboard link you can see that it also happened on a more
> >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
> >>> now in linux-next.
> >>>
> >>>> I'm also not sure why I'm on the cc for this.
> >>>
> >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
> >>> as maintainer of the file, which is the file where the crash happened.
> >>
> >> You need to use your reproducer to bisect and find the commit that
> >> caused this.  Otherwise you will continue to confuse people.
> >>
> >> get_maintainer.pl is not a good target for automated reporting
> >> especially against linux-next.
> >
> > Hi Eric,
> >
> > We will do bisection.
> > But I afraid it will not give perfect attribution for a number of reasons:
> >  - broken build/boot which happens sometimes for prolonged periods and
> > prohibits bisection
> >  - elusive races that can't be reproduced reliably and thus bisection
> > can give wrong results
> >  - bugs introduced too long ago (e.g. author email is not even valid today)
> >  - reproducers triggering more than 1 bug, so base bisection commit
> > can actually be for another bug, or bisection can switch from one bug
> > to another
> >  - last but not least, bugs without reproducers
> > Bisection will add useful information to the bug report, but it will
> > not necessary make attribution better than it is now.
> >
> > Do you have more examples where bugs were misreported? From what I see
> > current attrition works well. There are episodic fallouts, but well,
> > nothing is perfect in this world. Humans don't bisect frequently and
> > misreport sometimes. I think we just need to re-route bugs in such
> > cases.
> 
> I have yet to see syzbot make a good report.  Especially against
> linux-next.

It did result in a fix (thanks!): https://lkml.org/lkml/2018/8/16/47

So I'd call that a better-than-nothing report if not a great report?

There's some value just in timeliness; it's a lot easier for me to fix a
bug that I introduced in the last few days, with the change still fresh
in my mind....

--b.

Re: general protection fault in send_sigurg_to_task

[Dmitry Vyukov]

On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Dmitry Vyukov <dvyukov@google.com> writes:
>
>> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Dmitry Vyukov <dvyukov@google.com> writes:
>>>
>>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>>>>> syzbot has found a reproducer for the following crash on:
>>>>>>
>>>>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>>>>>> git tree:       linux-next
>>>>>
>>>>> I fetched linux-next but don't have 5ed5da74de9e.
>>>>
>>>> Hi Bruce,
>>>>
>>>> +Stephen for the disappeared linux-next commit.
>>>>
>>>> On the dashboard link you can see that it also happened on a more
>>>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
>>>> now in linux-next.
>>>>
>>>>> I'm also not sure why I'm on the cc for this.
>>>>
>>>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c"
>>>> as maintainer of the file, which is the file where the crash happened.
>>>
>>> You need to use your reproducer to bisect and find the commit that
>>> caused this.  Otherwise you will continue to confuse people.
>>>
>>> get_maintainer.pl is not a good target for automated reporting
>>> especially against linux-next.
>>
>> Hi Eric,
>>
>> We will do bisection.
>> But I afraid it will not give perfect attribution for a number of reasons:
>>  - broken build/boot which happens sometimes for prolonged periods and
>> prohibits bisection
>>  - elusive races that can't be reproduced reliably and thus bisection
>> can give wrong results
>>  - bugs introduced too long ago (e.g. author email is not even valid today)
>>  - reproducers triggering more than 1 bug, so base bisection commit
>> can actually be for another bug, or bisection can switch from one bug
>> to another
>>  - last but not least, bugs without reproducers
>> Bisection will add useful information to the bug report, but it will
>> not necessary make attribution better than it is now.
>>
>> Do you have more examples where bugs were misreported? From what I see
>> current attrition works well. There are episodic fallouts, but well,
>> nothing is perfect in this world. Humans don't bisect frequently and
>> misreport sometimes. I think we just need to re-route bugs in such
>> cases.
>
> I have yet to see syzbot make a good report.  Especially against
> linux-next.

Well, first of all, we are not aware of any massive problems because
nobody tells us. What are the systematic problems that affect lots of
reports?

I took few recent ones. Anything wrong with them?

https://lkml.org/lkml/2018/7/15/230
https://lkml.org/lkml/2018/7/18/992
https://lkml.org/lkml/2018/4/19/705
https://groups.google.com/forum/#!msg/syzkaller-bugs/F7KnbAmMa7E/VSbaYHyQCAAJ