On Mon, Aug 9, 2021 at 9:40 PM Shoaib Rao rao.shoaib@oracle.com wrote:
On 8/9/21 12:21 PM, Dmitry Vyukov wrote:
On Mon, 9 Aug 2021 at 21:16, Shoaib Rao rao.shoaib@oracle.com wrote:
On 8/9/21 11:06 AM, Dmitry Vyukov wrote:
On Mon, 9 Aug 2021 at 19:33, Shoaib Rao rao.shoaib@oracle.com wrote:
This seems like a false positive. 1) The function will not sleep because it only calls copy routine if the byte is present. 2). There is no difference between this new call and the older calls in unix_stream_read_generic().
Hi Shoaib,
Thanks for looking into this. Do you have any ideas on how to fix this tool's false positive? Tools with false positives are order of magnitude less useful than tools w/o false positives. E.g. do we turn it off on syzbot? But I don't remember any other false positives from "sleeping function called from invalid context" checker...
Before we take any action I would like to understand why the tool does not single out other calls to recv_actor in unix_stream_read_generic(). The context in all cases is the same. I also do not understand why the code would sleep, Let's assume the user provided address is bad, the code will return EFAULT, it will never sleep,
I always assumed that it's because if user pages are swapped out, it may need to read them back from disk.
Page faults occur all the time, the page may not even be in the cache or the mapping is not there (mmap), so I would not consider this a bug. The code should complain about all other calls as they are also copying to user pages. I must not be following some semantics for the code to be triggered but I can not figure that out. What is the recommended interface to do user copy from kernel?
Are you aware of the difference between a mutex and a spinlock ?
When copying data from/to user, you can not hold a spinlock.
Shoaib
if the kernel provided address is bad the system will panic. The only difference I see is that the new code holds 2 locks while the previous code held one lock, but the locks are acquired before the call to copy.
So please help me understand how the tool works. Even though I have evaluated the code carefully, there is always a possibility that the tool is correct.
Shoaib
On 8/8/21 4:38 PM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit: c2eecaa193ff pktgen: Remove redundant clone_skb override git tree: net-next console output: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/log.txt?x=12e3a6... kernel config: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/.config?x=aba0c2... dashboard link: https://urldefense.com/v3/__https://syzkaller.appspot.com/bug?extid=8760ca6c... compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1 syz repro: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.syz?x=15c5... C reproducer: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.c?x=10062a...
The issue was bisected to:
commit 314001f0bf927015e459c9d387d62a231fe93af3 Author: Rao Shoaib rao.shoaib@oracle.com Date: Sun Aug 1 07:57:07 2021 +0000
af_unix: Add OOB supportbisection log: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/bisect.txt?x=107... final oops: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/report.txt?x=127... console output: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/log.txt?x=14765f...
IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8760ca6c1ee783ac4abd@syzkaller.appspotmail.com Fixes: 314001f0bf92 ("af_unix: Add OOB support")
BUG: sleeping function called from invalid context at lib/iov_iter.c:619 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 8443, name: syz-executor700 2 locks held by syz-executor700/8443: #0: ffff888028fa0d00 (&u->iolock){+.+.}-{3:3}, at: unix_stream_read_generic+0x16c6/0x2190 net/unix/af_unix.c:2501 #1: ffff888028fa0df0 (&u->lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:354 [inline] #1: ffff888028fa0df0 (&u->lock){+.+.}-{2:2}, at: unix_stream_read_generic+0x16d0/0x2190 net/unix/af_unix.c:2502 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 1 PID: 8443 Comm: syz-executor700 Not tainted 5.14.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105 ___might_sleep.cold+0x1f1/0x237 kernel/sched/core.c:9154 __might_fault+0x6e/0x180 mm/memory.c:5258 _copy_to_iter+0x199/0x1600 lib/iov_iter.c:619 copy_to_iter include/linux/uio.h:139 [inline] simple_copy_to_iter+0x4c/0x70 net/core/datagram.c:519 __skb_datagram_iter+0x10f/0x770 net/core/datagram.c:425 skb_copy_datagram_iter+0x40/0x50 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3620 [inline] unix_stream_read_actor+0x78/0xc0 net/unix/af_unix.c:2701 unix_stream_recv_urg net/unix/af_unix.c:2433 [inline] unix_stream_read_generic+0x17cd/0x2190 net/unix/af_unix.c:2504 unix_stream_recvmsg+0xb1/0xf0 net/unix/af_unix.c:2717 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_recvmsg net/socket.c:958 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2622 ___sys_recvmsg+0x127/0x200 net/socket.c:2664 do_recvmmsg+0x24d/0x6d0 net/socket.c:2758 __sys_recvmmsg net/socket.c:2837 [inline] __do_sys_recvmmsg net/socket.c:2860 [inline] __se_sys_recvmmsg net/socket.c:2853 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2853 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43ef39 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:00007ffca8776d68 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043ef39 RDX: 0000000000000700 RSI: 0000000020001140 RDI: 0000000000000004 RBP: 0000000000402f20 R08: 0000000000000000 R09: 0000000000400488 R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000402fb0 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488
============================= [ BUG: Invalid wait context ] 5.14.0-rc3-syzkaller #0 Tainted: G W
syz-executor700/8443 is trying to lock: ffff8880212b6a28 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0xa3/0x180 mm/memory.c:5260 other info that might help us debug this: context-{4:4} 2 locks held by syz-executor700/8443: #0: ffff888028fa0d00 (&u->iolock){+.+.}-{3:3}, at: unix_stream_read_generic+0x16c6/0x2190 net/unix/af_unix.c:2501 #1: ffff888028fa0df0 (&u->lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:354 [inline] #1: ffff888028fa0df0 (&u->lock){+.+.}-{2:2}, at: unix_stream_read_generic+0x16d0/0x2190 net/unix/af_unix.c:2502 stack backtrace: CPU: 1 PID: 8443 Comm: syz-executor700 Tainted: G W 5.14.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105 print_lock_invalid_wait_context kernel/locking/lockdep.c:4666 [inline] check_wait_context kernel/locking/lockdep.c:4727 [inline] __lock_acquire.cold+0x213/0x3ab kernel/locking/lockdep.c:4965 lock_acquire kernel/locking/lockdep.c:5625 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590 __might_fault mm/memory.c:5261 [inline] __might_fault+0x106/0x180 mm/memory.c:5246 _copy_to_iter+0x199/0x1600 lib/iov_iter.c:619 copy_to_iter include/linux/uio.h:139 [inline] simple_copy_to_iter+0x4c/0x70 net/core/datagram.c:519 __skb_datagram_iter+0x10f/0x770 net/core/datagram.c:425 skb_copy_datagram_iter+0x40/0x50 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3620 [inline] unix_stream_read_actor+0x78/0xc0 net/unix/af_unix.c:2701 unix_stream_recv_urg net/unix/af_unix.c:2433 [inline] unix_stream_read_generic+0x17cd/0x2190 net/unix/af_unix.c:2504 unix_stream_recvmsg+0xb1/0xf0 net/unix/af_unix.c:2717 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_recvmsg net/socket.c:958 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2622 ___sys_recvmsg+0x127/0x200 net/socket.c:2664 do_recvmmsg+0x24d/0x6d0 net/socket.c:2758 __sys_recvmmsg net/socket.c:2837 [inline] __do_sys_recvmmsg net/socket.c:2860 [inline] __se_sys_recvmmsg net/socket.c:2853 [inline] __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2853 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43ef39 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:00007ffca8776d68 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043ef39 RDX: 0000000000000700 RSI: 0000000020001140 RDI: 0000000000000004 RBP: 0000000000402f20 R08: 0000000000000000 R09: 0000000000400488 R10: 0000000000000007 R11: 0000000000000246 R12: 0000
This report is generated by a bot. It may contain errors. See https://urldefense.com/v3/__https://goo.gl/tpsmEJ__%3B%21%21ACWV5N9M2RV99hQ%... for more information about syzbot. syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See: https://urldefense.com/v3/__https://goo.gl/tpsmEJ*status__%3BIw%21%21ACWV5N9... for how to communicate with syzbot. For information about bisection process see: https://urldefense.com/v3/__https://goo.gl/tpsmEJ*bisection__%3BIw%21%21ACWV... syzbot can test patches for this issue, for details see: https://urldefense.com/v3/__https://goo.gl/tpsmEJ*testing-patches__%3BIw%21%...
-- 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://urldefense.com/v3/__https://groups.google.com/d/msgid/syzkaller-bugs... .