Re: [syzbot] general protection fault in sock_from

public inbox for [email protected]
 help / color / mirror / Atom feed

* Re: [syzbot] general protection fault in sock_from_file
       [not found] <[email protected]>
@ 2021-08-30 19:22 ` Dmitry Vyukov
  2021-08-30 20:45 ` syzbot
  1 sibling, 0 replies; 9+ messages in thread
From: Dmitry Vyukov @ 2021-08-30 19:22 UTC (permalink / raw)
  To: syzbot, Jens Axboe, Pavel Begunkov, io-uring
  Cc: andrii, ast, bpf, daniel, davem, john.fastabend, kafai, kpsingh,
	kuba, linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

On Mon, 30 Aug 2021 at 21:19, syzbot
<[email protected]> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b851fe300000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]

+io_uring maintainers as this looks io_uring-related

> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> CPU: 1 PID: 6072 Comm: syz-executor.0 Not tainted 5.14.0-next-20210830-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
> RSP: 0018:ffffc9000a2df8e8 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90002f91000
> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
> RBP: ffff8880983c2c80 R08: ffffffff899aee40 R09: ffffffff81e21978
> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
> R13: 1ffff11013078599 R14: 0000000000000003 R15: ffff8880983c2c80
> FS:  00007fe7b0454700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005591dffa5180 CR3: 00000000974cb000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>  io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>  __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>  io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>  tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>  task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>  tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>  handle_signal_work kernel/entry/common.c:146 [inline]
>  exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>  exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>  __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>  syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>  do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x4665f9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fe7b0454188 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa
> RAX: 0000000000001000 RBX: 000000000056bf80 RCX: 00000000004665f9
> RDX: 0000000000000000 RSI: 000000000000688c RDI: 0000000000000003
> RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80
> R13: 00007fffeee6585f R14: 00007fe7b0454300 R15: 0000000000022000
> Modules linked in:
> ---[ end trace 6f9e359dd487b8fa ]---
> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
> RSP: 0018:ffffc9000a2df8e8 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90002f91000
> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
> RBP: ffff8880983c2c80 R08: ffffffff899aee40 R09: ffffffff81e21978
> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
> R13: 1ffff11013078599 R14: 0000000000000003 R15: ffff8880983c2c80
> FS:  00007fe7b0454700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fb81002c710 CR3: 00000000974cb000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess), 3 bytes skipped:
>    0:   ff c3                   inc    %ebx
>    2:   0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
>    7:   41 54                   push   %r12
>    9:   53                      push   %rbx
>    a:   48 89 fb                mov    %rdi,%rbx
>    d:   e8 85 e9 62 fa          callq  0xfa62e997
>   12:   48 8d 7b 28             lea    0x28(%rbx),%rdi
>   16:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
>   1d:   fc ff df
>   20:   48 89 fa                mov    %rdi,%rdx
>   23:   48 c1 ea 03             shr    $0x3,%rdx
> * 27:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
>   2b:   75 4f                   jne    0x7c
>   2d:   45 31 e4                xor    %r12d,%r12d
>   30:   48 81 7b 28 80 f1 8a    cmpq   $0xffffffff8a8af180,0x28(%rbx)
>   37:   8a
>   38:   74 0c                   je     0x46
>   3a:   e8                      .byte 0xe8
>   3b:   58                      pop    %rax
>   3c:   e9                      .byte 0xe9
>
>
> ---
> 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 [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000011360d05cacbb622%40google.com.

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

* Re: [syzbot] general protection fault in sock_from_file
       [not found] <[email protected]>
  2021-08-30 19:22 ` [syzbot] general protection fault in sock_from_file Dmitry Vyukov
@ 2021-08-30 20:45 ` syzbot
  2021-08-31  2:14   ` Jens Axboe
  1 sibling, 1 reply; 9+ messages in thread
From: syzbot @ 2021-08-30 20:45 UTC (permalink / raw)
  To: andrii, asml.silence, ast, axboe, bpf, daniel, davem, dvyukov,
	io-uring, john.fastabend, kafai, kpsingh, kuba, linux-kernel,
	netdev, songliubraving, syzkaller-bugs, yhs

syzbot has found a reproducer for the following issue on:

HEAD commit:    93717cde744f Add linux-next specific files for 20210830
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 io_sendmsg+0x98/0x640 fs/io_uring.c:4681
 io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
 __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
 io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
 tctx_task_work+0x166/0x610 fs/io_uring.c:2143
 task_work_run+0xdd/0x1a0 kernel/task_work.c:164
 tracehook_notify_signal include/linux/tracehook.h:212 [inline]
 handle_signal_work kernel/entry/common.c:146 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
 exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
 syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43fd49
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd6347b9d8 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa
RAX: 0000000000001000 RBX: 0000000000000003 RCX: 000000000043fd49
RDX: 0000000000000000 RSI: 000000000000688c RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004035d0
R13: 431bde82d7b634db R14: 00000000004ae018 R15: 0000000000400488
Modules linked in:
---[ end trace aa9bf60339277d03 ]---
RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
FS:  00000000013b5300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2cc6f84000 CR3: 000000001d355000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 3 bytes skipped:
   0:	ff c3                	inc    %ebx
   2:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
   7:	41 54                	push   %r12
   9:	53                   	push   %rbx
   a:	48 89 fb             	mov    %rdi,%rbx
   d:	e8 85 e9 62 fa       	callq  0xfa62e997
  12:	48 8d 7b 28          	lea    0x28(%rbx),%rdi
  16:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  1d:	fc ff df
  20:	48 89 fa             	mov    %rdi,%rdx
  23:	48 c1 ea 03          	shr    $0x3,%rdx
* 27:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
  2b:	75 4f                	jne    0x7c
  2d:	45 31 e4             	xor    %r12d,%r12d
  30:	48 81 7b 28 80 f1 8a 	cmpq   $0xffffffff8a8af180,0x28(%rbx)
  37:	8a
  38:	74 0c                	je     0x46
  3a:	e8                   	.byte 0xe8
  3b:	58                   	pop    %rax
  3c:	e9                   	.byte 0xe9


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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-30 20:45 ` syzbot
@ 2021-08-31  2:14   ` Jens Axboe
  2021-08-31  9:19     ` Hao Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2021-08-31  2:14 UTC (permalink / raw)
  To: syzbot, andrii, asml.silence, ast, bpf, daniel, davem, dvyukov,
	io-uring, john.fastabend, kafai, kpsingh, kuba, linux-kernel,
	netdev, songliubraving, syzkaller-bugs, yhs, Hao Xu

On 8/30/21 2:45 PM, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
> 
> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>  io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>  __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>  io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>  tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>  task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>  tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>  handle_signal_work kernel/entry/common.c:146 [inline]
>  exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>  exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>  __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>  syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>  do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x43fd49

Hao, this is due to:

commit a8295b982c46d4a7c259a4cdd58a2681929068a9
Author: Hao Xu <[email protected]>
Date:   Fri Aug 27 17:46:09 2021 +0800

    io_uring: fix failed linkchain code logic

which causes some weirdly super long chains from that single sqe.
Can you take a look, please?

-- 
Jens Axboe


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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31  2:14   ` Jens Axboe
@ 2021-08-31  9:19     ` Hao Xu
  2021-08-31  9:42       ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Hao Xu @ 2021-08-31  9:19 UTC (permalink / raw)
  To: Jens Axboe, syzbot, andrii, asml.silence, ast, bpf, daniel, davem,
	dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

在 2021/8/31 上午10:14, Jens Axboe 写道:
> On 8/30/21 2:45 PM, syzbot wrote:
>> syzbot has found a reproducer for the following issue on:
>>
>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>> git tree:       linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: [email protected]
>>
>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>>   io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>   io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>   __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>   io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>   tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>   task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>   tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>   handle_signal_work kernel/entry/common.c:146 [inline]
>>   exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>   exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>   __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>   syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>   do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>   entry_SYSCALL_64_after_hwframe+0x44/0xae
>> RIP: 0033:0x43fd49
> 
> Hao, this is due to:
> 
> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
> Author: Hao Xu <[email protected]>
> Date:   Fri Aug 27 17:46:09 2021 +0800
> 
>      io_uring: fix failed linkchain code logic
> 
> which causes some weirdly super long chains from that single sqe.
> Can you take a look, please?
Sure, I'm working on this.
> 


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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31  9:19     ` Hao Xu
@ 2021-08-31  9:42       ` Pavel Begunkov
  2021-08-31 11:05         ` Hao Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-31  9:42 UTC (permalink / raw)
  To: Hao Xu, Jens Axboe, syzbot, andrii, ast, bpf, daniel, davem,
	dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

On 8/31/21 10:19 AM, Hao Xu wrote:
> 在 2021/8/31 上午10:14, Jens Axboe 写道:
>> On 8/30/21 2:45 PM, syzbot wrote:
>>> syzbot has found a reproducer for the following issue on:
>>>
>>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>>> git tree:       linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: [email protected]
>>>
>>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>> Call Trace:
>>>   io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>>   io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>>   __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>>   io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>>   tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>>   task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>>   tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>>   handle_signal_work kernel/entry/common.c:146 [inline]
>>>   exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>>   exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>>   __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>>   syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>>   do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>>   entry_SYSCALL_64_after_hwframe+0x44/0xae
>>> RIP: 0033:0x43fd49
>>
>> Hao, this is due to:
>>
>> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
>> Author: Hao Xu <[email protected]>
>> Date:   Fri Aug 27 17:46:09 2021 +0800
>>
>>      io_uring: fix failed linkchain code logic
>>
>> which causes some weirdly super long chains from that single sqe.
>> Can you take a look, please?
> Sure, I'm working on this.

Ah, saw it after sending a patch. It's nothing too curious, just
a small error in logic. More interesting that we don't have a
test case covering it, we should definitely add something.

-- 
Pavel Begunkov

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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31  9:42       ` Pavel Begunkov
@ 2021-08-31 11:05         ` Hao Xu
  2021-08-31 11:26           ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Hao Xu @ 2021-08-31 11:05 UTC (permalink / raw)
  To: Pavel Begunkov, Jens Axboe, syzbot, andrii, ast, bpf, daniel,
	davem, dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

在 2021/8/31 下午5:42, Pavel Begunkov 写道:
> On 8/31/21 10:19 AM, Hao Xu wrote:
>> 在 2021/8/31 上午10:14, Jens Axboe 写道:
>>> On 8/30/21 2:45 PM, syzbot wrote:
>>>> syzbot has found a reproducer for the following issue on:
>>>>
>>>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>>>> git tree:       linux-next
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>>>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>>>
>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>> Reported-by: [email protected]
>>>>
>>>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>>>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>>>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>>>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>>>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>>>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>>>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>>>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>>>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>>>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>> Call Trace:
>>>>    io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>>>    io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>>>    __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>>>    io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>>>    tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>>>    task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>>>    tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>>>    handle_signal_work kernel/entry/common.c:146 [inline]
>>>>    exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>>>    exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>>>    __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>>>    syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>>>    do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xae
>>>> RIP: 0033:0x43fd49
>>>
>>> Hao, this is due to:
>>>
>>> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
>>> Author: Hao Xu <[email protected]>
>>> Date:   Fri Aug 27 17:46:09 2021 +0800
>>>
>>>       io_uring: fix failed linkchain code logic
>>>
>>> which causes some weirdly super long chains from that single sqe.
>>> Can you take a look, please?
>> Sure, I'm working on this.
> 
> Ah, saw it after sending a patch. It's nothing too curious, just
> a small error in logic. More interesting that we don't have a
> test case covering it, we should definitely add something.
> 
Saw your patch after coding my fix..😂
Since my email client doesn't receive your patch(only saw it in
webpage https://lore.kernel.org/), I put my comment here:
>  fs/io_uring.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 473a977c7979..a531c7324ea8 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -6717,6 +6717,8 @@ static inline void io_queue_sqe(struct io_kiocb *req)
>  	if (likely(!(req->flags & (REQ_F_FORCE_ASYNC | REQ_F_FAIL)))) {
>  		__io_queue_sqe(req);
>  	} else if (req->flags & REQ_F_FAIL) {
> +		/* fail all, we don't submit */
> +		req->flags &= ~REQ_F_HARDLINK;
maybe set REQ_F_LINK here?
>  		io_req_complete_failed(req, req->result);
>  	} else {
>  		int ret = io_req_prep_async(req);
> -- 




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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31 11:05         ` Hao Xu
@ 2021-08-31 11:26           ` Pavel Begunkov
  2021-08-31 11:48             ` Hao Xu
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-31 11:26 UTC (permalink / raw)
  To: Hao Xu, Jens Axboe, syzbot, andrii, ast, bpf, daniel, davem,
	dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

On 8/31/21 12:05 PM, Hao Xu wrote:
> 在 2021/8/31 下午5:42, Pavel Begunkov 写道:
>> On 8/31/21 10:19 AM, Hao Xu wrote:
>>> 在 2021/8/31 上午10:14, Jens Axboe 写道:
>>>> On 8/30/21 2:45 PM, syzbot wrote:
>>>>> syzbot has found a reproducer for the following issue on:
>>>>>
>>>>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>>>>> git tree:       linux-next
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>>>>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>>>>
>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>> Reported-by: [email protected]
>>>>>
>>>>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>>>>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>>>>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>>>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>>>>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>>>>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>>>>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>>>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>>>>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>>>>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>>>>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>>>>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>>> Call Trace:
>>>>>    io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>>>>    io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>>>>    __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>>>>    io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>>>>    tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>>>>    task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>>>>    tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>>>>    handle_signal_work kernel/entry/common.c:146 [inline]
>>>>>    exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>>>>    exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>>>>    __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>>>>    syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>>>>    do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xae
>>>>> RIP: 0033:0x43fd49
>>>>
>>>> Hao, this is due to:
>>>>
>>>> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
>>>> Author: Hao Xu <[email protected]>
>>>> Date:   Fri Aug 27 17:46:09 2021 +0800
>>>>
>>>>       io_uring: fix failed linkchain code logic
>>>>
>>>> which causes some weirdly super long chains from that single sqe.
>>>> Can you take a look, please?
>>> Sure, I'm working on this.
>>
>> Ah, saw it after sending a patch. It's nothing too curious, just
>> a small error in logic. More interesting that we don't have a
>> test case covering it, we should definitely add something.
>>
> Saw your patch after coding my fix..😂
> Since my email client doesn't receive your patch(only saw it in
> webpage https://lore.kernel.org/), I put my comment here:

Hmm, does it happen often? I'll CC you


>>  fs/io_uring.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 473a977c7979..a531c7324ea8 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -6717,6 +6717,8 @@ static inline void io_queue_sqe(struct io_kiocb *req)
>>      if (likely(!(req->flags & (REQ_F_FORCE_ASYNC | REQ_F_FAIL)))) {
>>          __io_queue_sqe(req);
>>      } else if (req->flags & REQ_F_FAIL) {
>> +        /* fail all, we don't submit */
>> +        req->flags &= ~REQ_F_HARDLINK;
> maybe set REQ_F_LINK here?

if (unlikely((req->flags & REQ_F_FAIL) &&
	     !(req->flags & REQ_F_HARDLINK))) {
	posted |= (req->link != NULL);
	io_fail_links(req);
}

The problem is hardlink, normal will be failed. But there is indeed
a problem with both patches, 

if (req->flags & (REQ_F_LINK | REQ_F_HARDLINK))
	// kill linked

Will resend with some tests on top


>>          io_req_complete_failed(req, req->result);
>>      } else {
>>          int ret = io_req_prep_async(req);

-- 
Pavel Begunkov

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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31 11:26           ` Pavel Begunkov
@ 2021-08-31 11:48             ` Hao Xu
  2021-08-31 11:50               ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Hao Xu @ 2021-08-31 11:48 UTC (permalink / raw)
  To: Pavel Begunkov, Jens Axboe, syzbot, andrii, ast, bpf, daniel,
	davem, dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

在 2021/8/31 下午7:26, Pavel Begunkov 写道:
> On 8/31/21 12:05 PM, Hao Xu wrote:
>> 在 2021/8/31 下午5:42, Pavel Begunkov 写道:
>>> On 8/31/21 10:19 AM, Hao Xu wrote:
>>>> 在 2021/8/31 上午10:14, Jens Axboe 写道:
>>>>> On 8/30/21 2:45 PM, syzbot wrote:
>>>>>> syzbot has found a reproducer for the following issue on:
>>>>>>
>>>>>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>>>>>> git tree:       linux-next
>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>>>>>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>>>>>
>>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>>> Reported-by: [email protected]
>>>>>>
>>>>>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>>>>>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>>>>>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>>>>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>>>>>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>>>>>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>>>>>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>>>>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>>>>>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>>>>>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>>>>>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>>>>>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>>>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>>>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>>>> Call Trace:
>>>>>>     io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>>>>>     io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>>>>>     __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>>>>>     io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>>>>>     tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>>>>>     task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>>>>>     tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>>>>>     handle_signal_work kernel/entry/common.c:146 [inline]
>>>>>>     exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>>>>>     exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>>>>>     __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>>>>>     syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>>>>>     do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>>>>>     entry_SYSCALL_64_after_hwframe+0x44/0xae
>>>>>> RIP: 0033:0x43fd49
>>>>>
>>>>> Hao, this is due to:
>>>>>
>>>>> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
>>>>> Author: Hao Xu <[email protected]>
>>>>> Date:   Fri Aug 27 17:46:09 2021 +0800
>>>>>
>>>>>        io_uring: fix failed linkchain code logic
>>>>>
>>>>> which causes some weirdly super long chains from that single sqe.
>>>>> Can you take a look, please?
>>>> Sure, I'm working on this.
>>>
>>> Ah, saw it after sending a patch. It's nothing too curious, just
>>> a small error in logic. More interesting that we don't have a
>>> test case covering it, we should definitely add something.
>>>
>> Saw your patch after coding my fix..😂
>> Since my email client doesn't receive your patch(only saw it in
>> webpage https://lore.kernel.org/), I put my comment here:
> 
> Hmm, does it happen often? I'll CC you
Uncommon, somestimes there is delay.
> 
> 
>>>   fs/io_uring.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>> index 473a977c7979..a531c7324ea8 100644
>>> --- a/fs/io_uring.c
>>> +++ b/fs/io_uring.c
>>> @@ -6717,6 +6717,8 @@ static inline void io_queue_sqe(struct io_kiocb *req)
>>>       if (likely(!(req->flags & (REQ_F_FORCE_ASYNC | REQ_F_FAIL)))) {
>>>           __io_queue_sqe(req);
>>>       } else if (req->flags & REQ_F_FAIL) {
>>> +        /* fail all, we don't submit */
>>> +        req->flags &= ~REQ_F_HARDLINK;
>> maybe set REQ_F_LINK here?
> 
> if (unlikely((req->flags & REQ_F_FAIL) &&
> 	     !(req->flags & REQ_F_HARDLINK))) {
> 	posted |= (req->link != NULL);
> 	io_fail_links(req);
> }
> 
> The problem is hardlink, normal will be failed. But there is indeed
> a problem with both patches,
> 
> if (req->flags & (REQ_F_LINK | REQ_F_HARDLINK))
> 	// kill linked
Yeah, if we don't have REQ_F_LINK, io_req_complete_post() won't go to
the disarm branch
> 
> Will resend with some tests on top
> 
> 
>>>           io_req_complete_failed(req, req->result);
>>>       } else {
>>>           int ret = io_req_prep_async(req);
> 


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

* Re: [syzbot] general protection fault in sock_from_file
  2021-08-31 11:48             ` Hao Xu
@ 2021-08-31 11:50               ` Pavel Begunkov
  0 siblings, 0 replies; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-31 11:50 UTC (permalink / raw)
  To: Hao Xu, Jens Axboe, syzbot, andrii, ast, bpf, daniel, davem,
	dvyukov, io-uring, john.fastabend, kafai, kpsingh, kuba,
	linux-kernel, netdev, songliubraving, syzkaller-bugs, yhs

On 8/31/21 12:48 PM, Hao Xu wrote:
> 在 2021/8/31 下午7:26, Pavel Begunkov 写道:
>> On 8/31/21 12:05 PM, Hao Xu wrote:
>>> 在 2021/8/31 下午5:42, Pavel Begunkov 写道:
>>>> On 8/31/21 10:19 AM, Hao Xu wrote:
>>>>> 在 2021/8/31 上午10:14, Jens Axboe 写道:
>>>>>> On 8/30/21 2:45 PM, syzbot wrote:
>>>>>>> syzbot has found a reproducer for the following issue on:
>>>>>>>
>>>>>>> HEAD commit:    93717cde744f Add linux-next specific files for 20210830
>>>>>>> git tree:       linux-next
>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15200fad300000
>>>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=c643ef5289990dd1
>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=f9704d1878e290eddf73
>>>>>>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
>>>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=111f5f9d300000
>>>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1651a415300000
>>>>>>>
>>>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>>>> Reported-by: [email protected]
>>>>>>>
>>>>>>> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
>>>>>>> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
>>>>>>> CPU: 0 PID: 6548 Comm: syz-executor433 Not tainted 5.14.0-next-20210830-syzkaller #0
>>>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>>>>>> RIP: 0010:sock_from_file+0x20/0x90 net/socket.c:505
>>>>>>> Code: f5 ff ff ff c3 0f 1f 44 00 00 41 54 53 48 89 fb e8 85 e9 62 fa 48 8d 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 4f 45 31 e4 48 81 7b 28 80 f1 8a 8a 74 0c e8 58 e9
>>>>>>> RSP: 0018:ffffc90002caf8e8 EFLAGS: 00010206
>>>>>>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>>>>>>> RDX: 0000000000000005 RSI: ffffffff8713203b RDI: 0000000000000028
>>>>>>> RBP: ffff888019fc0780 R08: ffffffff899aee40 R09: ffffffff81e21978
>>>>>>> R10: 0000000000000027 R11: 0000000000000009 R12: dffffc0000000000
>>>>>>> R13: 1ffff110033f80f9 R14: 0000000000000003 R15: ffff888019fc0780
>>>>>>> FS:  00000000013b5300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
>>>>>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>> CR2: 00000000004ae0f0 CR3: 000000001d355000 CR4: 00000000001506f0
>>>>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>>>>> Call Trace:
>>>>>>>     io_sendmsg+0x98/0x640 fs/io_uring.c:4681
>>>>>>>     io_issue_sqe+0x14de/0x6ba0 fs/io_uring.c:6578
>>>>>>>     __io_queue_sqe+0x90/0xb50 fs/io_uring.c:6864
>>>>>>>     io_req_task_submit+0xbf/0x1b0 fs/io_uring.c:2218
>>>>>>>     tctx_task_work+0x166/0x610 fs/io_uring.c:2143
>>>>>>>     task_work_run+0xdd/0x1a0 kernel/task_work.c:164
>>>>>>>     tracehook_notify_signal include/linux/tracehook.h:212 [inline]
>>>>>>>     handle_signal_work kernel/entry/common.c:146 [inline]
>>>>>>>     exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
>>>>>>>     exit_to_user_mode_prepare+0x256/0x290 kernel/entry/common.c:209
>>>>>>>     __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
>>>>>>>     syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302
>>>>>>>     do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
>>>>>>>     entry_SYSCALL_64_after_hwframe+0x44/0xae
>>>>>>> RIP: 0033:0x43fd49
>>>>>>
>>>>>> Hao, this is due to:
>>>>>>
>>>>>> commit a8295b982c46d4a7c259a4cdd58a2681929068a9
>>>>>> Author: Hao Xu <[email protected]>
>>>>>> Date:   Fri Aug 27 17:46:09 2021 +0800
>>>>>>
>>>>>>        io_uring: fix failed linkchain code logic
>>>>>>
>>>>>> which causes some weirdly super long chains from that single sqe.
>>>>>> Can you take a look, please?
>>>>> Sure, I'm working on this.
>>>>
>>>> Ah, saw it after sending a patch. It's nothing too curious, just
>>>> a small error in logic. More interesting that we don't have a
>>>> test case covering it, we should definitely add something.
>>>>
>>> Saw your patch after coding my fix..😂
>>> Since my email client doesn't receive your patch(only saw it in
>>> webpage https://lore.kernel.org/), I put my comment here:
>>
>> Hmm, does it happen often? I'll CC you
> Uncommon, somestimes there is delay.
>>
>>
>>>>   fs/io_uring.c | 2 ++
>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>>> index 473a977c7979..a531c7324ea8 100644
>>>> --- a/fs/io_uring.c
>>>> +++ b/fs/io_uring.c
>>>> @@ -6717,6 +6717,8 @@ static inline void io_queue_sqe(struct io_kiocb *req)
>>>>       if (likely(!(req->flags & (REQ_F_FORCE_ASYNC | REQ_F_FAIL)))) {
>>>>           __io_queue_sqe(req);
>>>>       } else if (req->flags & REQ_F_FAIL) {
>>>> +        /* fail all, we don't submit */
>>>> +        req->flags &= ~REQ_F_HARDLINK;
>>> maybe set REQ_F_LINK here?
>>
>> if (unlikely((req->flags & REQ_F_FAIL) &&
>>          !(req->flags & REQ_F_HARDLINK))) {
>>     posted |= (req->link != NULL);
>>     io_fail_links(req);
>> }
>>
>> The problem is hardlink, normal will be failed. But there is indeed
>> a problem with both patches,
>>
>> if (req->flags & (REQ_F_LINK | REQ_F_HARDLINK))
>>     // kill linked
> Yeah, if we don't have REQ_F_LINK, io_req_complete_post() won't go to
> the disarm branch

Ah, that's what you meant, right. Good catch!


>>
>> Will resend with some tests on top
>>
>>
>>>>           io_req_complete_failed(req, req->result);
>>>>       } else {
>>>>           int ret = io_req_prep_async(req);
>>
> 

-- 
Pavel Begunkov

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

end of thread, other threads:[~2021-08-31 11:51 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <[email protected]>
2021-08-30 19:22 ` [syzbot] general protection fault in sock_from_file Dmitry Vyukov
2021-08-30 20:45 ` syzbot
2021-08-31  2:14   ` Jens Axboe
2021-08-31  9:19     ` Hao Xu
2021-08-31  9:42       ` Pavel Begunkov
2021-08-31 11:05         ` Hao Xu
2021-08-31 11:26           ` Pavel Begunkov
2021-08-31 11:48             ` Hao Xu
2021-08-31 11:50               ` Pavel Begunkov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox