1. 31 8月, 2021 1 次提交
    • E
      af_unix: fix potential NULL deref in unix_dgram_connect() · dc56ad70
      Eric Dumazet 提交于
      syzbot was able to trigger NULL deref in unix_dgram_connect() [1]
      
      This happens in
      
      	if (unix_peer(sk))
      		sk->sk_state = other->sk_state = TCP_ESTABLISHED; // crash because @other is NULL
      
      Because locks have been dropped, unix_peer() might be non NULL,
      while @other is NULL (AF_UNSPEC case)
      
      We need to move code around, so that we no longer access
      unix_peer() and sk_state while locks have been released.
      
      [1]
      general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
      CPU: 0 PID: 10341 Comm: syz-executor239 Not tainted 5.14.0-rc7-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:unix_dgram_connect+0x32a/0xc60 net/unix/af_unix.c:1226
      Code: 00 00 45 31 ed 49 83 bc 24 f8 05 00 00 00 74 69 e8 eb 5b a6 f9 48 8d 7d 12 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 e0 07 00 00
      RSP: 0018:ffffc9000a89fcd8 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000
      RDX: 0000000000000002 RSI: ffffffff87cf4ef5 RDI: 0000000000000012
      RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88802e1917c3
      R10: ffffffff87cf4eba R11: 0000000000000001 R12: ffff88802e191740
      R13: 0000000000000000 R14: ffff88802e191d38 R15: ffff88802e1917c0
      FS:  00007f3eb0052700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004787d0 CR3: 0000000029c0a000 CR4: 00000000001506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       __sys_connect_file+0x155/0x1a0 net/socket.c:1890
       __sys_connect+0x161/0x190 net/socket.c:1907
       __do_sys_connect net/socket.c:1917 [inline]
       __se_sys_connect net/socket.c:1914 [inline]
       __x64_sys_connect+0x6f/0xb0 net/socket.c:1914
       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:0x446a89
      Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 a1 15 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 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f3eb0052208 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 00000000004cc4d8 RCX: 0000000000446a89
      RDX: 000000000000006e RSI: 0000000020000180 RDI: 0000000000000003
      RBP: 00000000004cc4d0 R08: 00007f3eb0052700 R09: 0000000000000000
      R10: 00007f3eb0052700 R11: 0000000000000246 R12: 00000000004cc4dc
      R13: 00007ffd791e79cf R14: 00007f3eb0052300 R15: 0000000000022000
      Modules linked in:
      ---[ end trace 4eb809357514968c ]---
      RIP: 0010:unix_dgram_connect+0x32a/0xc60 net/unix/af_unix.c:1226
      Code: 00 00 45 31 ed 49 83 bc 24 f8 05 00 00 00 74 69 e8 eb 5b a6 f9 48 8d 7d 12 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 e0 07 00 00
      RSP: 0018:ffffc9000a89fcd8 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000
      RDX: 0000000000000002 RSI: ffffffff87cf4ef5 RDI: 0000000000000012
      RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88802e1917c3
      R10: ffffffff87cf4eba R11: 0000000000000001 R12: ffff88802e191740
      R13: 0000000000000000 R14: ffff88802e191d38 R15: ffff88802e1917c0
      FS:  00007f3eb0052700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd791fe960 CR3: 0000000029c0a000 CR4: 00000000001506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 83301b53 ("af_unix: Set TCP_ESTABLISHED for datagram sockets too")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Cong Wang <cong.wang@bytedance.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc56ad70
  2. 23 8月, 2021 1 次提交
    • J
      af_unix: Fix NULL pointer bug in unix_shutdown · d359902d
      Jiang Wang 提交于
      Commit 94531cfc ("af_unix: Add unix_stream_proto for sockmap")
      introduced a bug for af_unix SEQPACKET type. In unix_shutdown, the
      unhash function will call prot->unhash(), which is NULL for SEQPACKET.
      And kernel will panic. On ARM32, it will show following messages: (it
      likely affects x86 too).
      
      Fix the bug by checking the prot->unhash is NULL or not first.
      
      Kernel log:
      <--- cut here ---
       Unable to handle kernel NULL pointer dereference at virtual address
      00000000
       pgd = 2fba1ffb
       *pgd=00000000
       Internal error: Oops: 80000005 [#1] PREEMPT SMP THUMB2
       Modules linked in:
       CPU: 1 PID: 1999 Comm: falkon Tainted: G        W
      5.14.0-rc5-01175-g94531cfc-dirty #9240
       Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
       PC is at 0x0
       LR is at unix_shutdown+0x81/0x1a8
       pc : [<00000000>]    lr : [<c08f3311>]    psr: 600f0013
       sp : e45aff70  ip : e463a3c0  fp : beb54f04
       r10: 00000125  r9 : e45ae000  r8 : c4a56664
       r7 : 00000001  r6 : c4a56464  r5 : 00000001  r4 : c4a56400
       r3 : 00000000  r2 : c5a6b180  r1 : 00000000  r0 : c4a56400
       Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
       Control: 50c5387d  Table: 05aa804a  DAC: 00000051
       Register r0 information: slab PING start c4a56400 pointer offset 0
       Register r1 information: NULL pointer
       Register r2 information: slab task_struct start c5a6b180 pointer offset 0
       Register r3 information: NULL pointer
       Register r4 information: slab PING start c4a56400 pointer offset 0
       Register r5 information: non-paged memory
       Register r6 information: slab PING start c4a56400 pointer offset 100
       Register r7 information: non-paged memory
       Register r8 information: slab PING start c4a56400 pointer offset 612
       Register r9 information: non-slab/vmalloc memory
       Register r10 information: non-paged memory
       Register r11 information: non-paged memory
       Register r12 information: slab filp start e463a3c0 pointer offset 0
       Process falkon (pid: 1999, stack limit = 0x9ec48895)
       Stack: (0xe45aff70 to 0xe45b0000)
       ff60:                                     e45ae000 c5f26a00 00000000 00000125
       ff80: c0100264 c07f7fa3 beb54f04 fffffff7 00000001 e6f3fc0e b5e5e9ec beb54ec4
       ffa0: b5da0ccc c010024b b5e5e9ec beb54ec4 0000000f 00000000 00000000 beb54ebc
       ffc0: b5e5e9ec beb54ec4 b5da0ccc 00000125 beb54f58 00785238 beb5529c beb54f04
       ffe0: b5da1e24 beb54eac b301385c b62b6ee8 600f0030 0000000f 00000000 00000000
       [<c08f3311>] (unix_shutdown) from [<c07f7fa3>] (__sys_shutdown+0x2f/0x50)
       [<c07f7fa3>] (__sys_shutdown) from [<c010024b>]
      (__sys_trace_return+0x1/0x16)
       Exception stack(0xe45affa8 to 0xe45afff0)
      
      Fixes: 94531cfc ("af_unix: Add unix_stream_proto for sockmap")
      Reported-by: NDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: NJiang Wang <jiang.wang@bytedance.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NKuniyuki Iwashima <kuniyu@amazon.co.jp>
      Link: https://lore.kernel.org/bpf/20210821180738.1151155-1-jiang.wang@bytedance.com
      d359902d
  3. 17 8月, 2021 2 次提交
  4. 16 8月, 2021 1 次提交
  5. 15 8月, 2021 1 次提交
  6. 14 8月, 2021 1 次提交
  7. 04 8月, 2021 1 次提交
  8. 29 7月, 2021 1 次提交
    • M
      af_unix: fix garbage collect vs MSG_PEEK · cbcf0112
      Miklos Szeredi 提交于
      unix_gc() assumes that candidate sockets can never gain an external
      reference (i.e.  be installed into an fd) while the unix_gc_lock is
      held.  Except for MSG_PEEK this is guaranteed by modifying inflight
      count under the unix_gc_lock.
      
      MSG_PEEK does not touch any variable protected by unix_gc_lock (file
      count is not), yet it needs to be serialized with garbage collection.
      Do this by locking/unlocking unix_gc_lock:
      
       1) increment file count
      
       2) lock/unlock barrier to make sure incremented file count is visible
          to garbage collection
      
       3) install file into fd
      
      This is a lock barrier (unlike smp_mb()) that ensures that garbage
      collection is run completely before or completely after the barrier.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cbcf0112
  9. 16 7月, 2021 5 次提交
  10. 30 6月, 2021 1 次提交
  11. 22 6月, 2021 8 次提交
  12. 17 6月, 2021 1 次提交
    • E
      net/af_unix: fix a data-race in unix_dgram_sendmsg / unix_release_sock · a494bd64
      Eric Dumazet 提交于
      While unix_may_send(sk, osk) is called while osk is locked, it appears
      unix_release_sock() can overwrite unix_peer() after this lock has been
      released, making KCSAN unhappy.
      
      Changing unix_release_sock() to access/change unix_peer()
      before lock is released should fix this issue.
      
      BUG: KCSAN: data-race in unix_dgram_sendmsg / unix_release_sock
      
      write to 0xffff88810465a338 of 8 bytes by task 20852 on cpu 1:
       unix_release_sock+0x4ed/0x6e0 net/unix/af_unix.c:558
       unix_release+0x2f/0x50 net/unix/af_unix.c:859
       __sock_release net/socket.c:599 [inline]
       sock_close+0x6c/0x150 net/socket.c:1258
       __fput+0x25b/0x4e0 fs/file_table.c:280
       ____fput+0x11/0x20 fs/file_table.c:313
       task_work_run+0xae/0x130 kernel/task_work.c:164
       tracehook_notify_resume include/linux/tracehook.h:189 [inline]
       exit_to_user_mode_loop kernel/entry/common.c:175 [inline]
       exit_to_user_mode_prepare+0x156/0x190 kernel/entry/common.c:209
       __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
       syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:302
       do_syscall_64+0x56/0x90 arch/x86/entry/common.c:57
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      read to 0xffff88810465a338 of 8 bytes by task 20888 on cpu 0:
       unix_may_send net/unix/af_unix.c:189 [inline]
       unix_dgram_sendmsg+0x923/0x1610 net/unix/af_unix.c:1712
       sock_sendmsg_nosec net/socket.c:654 [inline]
       sock_sendmsg net/socket.c:674 [inline]
       ____sys_sendmsg+0x360/0x4d0 net/socket.c:2350
       ___sys_sendmsg net/socket.c:2404 [inline]
       __sys_sendmmsg+0x315/0x4b0 net/socket.c:2490
       __do_sys_sendmmsg net/socket.c:2519 [inline]
       __se_sys_sendmmsg net/socket.c:2516 [inline]
       __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2516
       do_syscall_64+0x4a/0x90 arch/x86/entry/common.c:47
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      value changed: 0xffff888167905400 -> 0x0000000000000000
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 20888 Comm: syz-executor.0 Not tainted 5.13.0-rc5-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a494bd64
  13. 11 6月, 2021 1 次提交
  14. 24 1月, 2021 3 次提交
  15. 14 10月, 2020 1 次提交
  16. 22 9月, 2020 1 次提交
  17. 24 8月, 2020 1 次提交
  18. 20 7月, 2020 1 次提交
  19. 29 2月, 2020 2 次提交
  20. 28 2月, 2020 2 次提交
  21. 25 2月, 2020 1 次提交
  22. 06 2月, 2020 1 次提交
    • Q
      skbuff: fix a data race in skb_queue_len() · 86b18aaa
      Qian Cai 提交于
      sk_buff.qlen can be accessed concurrently as noticed by KCSAN,
      
       BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_dgram_sendmsg
      
       read to 0xffff8a1b1d8a81c0 of 4 bytes by task 5371 on cpu 96:
        unix_dgram_sendmsg+0x9a9/0xb70 include/linux/skbuff.h:1821
      				 net/unix/af_unix.c:1761
        ____sys_sendmsg+0x33e/0x370
        ___sys_sendmsg+0xa6/0xf0
        __sys_sendmsg+0x69/0xf0
        __x64_sys_sendmsg+0x51/0x70
        do_syscall_64+0x91/0xb47
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       write to 0xffff8a1b1d8a81c0 of 4 bytes by task 1 on cpu 99:
        __skb_try_recv_from_queue+0x327/0x410 include/linux/skbuff.h:2029
        __skb_try_recv_datagram+0xbe/0x220
        unix_dgram_recvmsg+0xee/0x850
        ____sys_recvmsg+0x1fb/0x210
        ___sys_recvmsg+0xa2/0xf0
        __sys_recvmsg+0x66/0xf0
        __x64_sys_recvmsg+0x51/0x70
        do_syscall_64+0x91/0xb47
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Since only the read is operating as lockless, it could introduce a logic
      bug in unix_recvq_full() due to the load tearing. Fix it by adding
      a lockless variant of skb_queue_len() and unix_recvq_full() where
      READ_ONCE() is on the read while WRITE_ONCE() is on the write similar to
      the commit d7d16a89 ("net: add skb_queue_empty_lockless()").
      Signed-off-by: NQian Cai <cai@lca.pw>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86b18aaa
  23. 13 12月, 2019 1 次提交
    • K
      unix: Show number of pending scm files of receive queue in fdinfo · 3c32da19
      Kirill Tkhai 提交于
      Unix sockets like a block box. You never know what is stored there:
      there may be a file descriptor holding a mount or a block device,
      or there may be whole universes with namespaces, sockets with receive
      queues full of sockets etc.
      
      The patch adds a little debug and accounts number of files (not recursive),
      which is in receive queue of a unix socket. Sometimes this is useful
      to determine, that socket should be investigated or which task should
      be killed to put reference counter on a resourse.
      
      v2: Pass correct argument to lockdep
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c32da19
  24. 10 12月, 2019 1 次提交