1. 08 Apr, 2021 1 commit
  2. 06 Apr, 2021 6 commits
  3. 02 Apr, 2021 5 commits
  4. 26 Mar, 2021 5 commits
  5. 25 Mar, 2021 10 commits
  6. 24 Mar, 2021 1 commit
  7. 23 Mar, 2021 2 commits
    • Meng Yu's avatar
      Bluetooth: Remove trailing semicolon in macros · c29fb5f6
      Meng Yu authored
      remove trailing semicolon in macros and coding style fix.
      Signed-off-by: default avatarMeng Yu <yumeng18@huawei.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c29fb5f6
    • Archie Pusaka's avatar
      Bluetooth: check for zapped sk before connecting · 3af70b39
      Archie Pusaka authored
      There is a possibility of receiving a zapped sock on
      l2cap_sock_connect(). This could lead to interesting crashes, one
      such case is tearing down an already tore l2cap_sock as is happened
      with this call trace:
      
      __dump_stack lib/dump_stack.c:15 [inline]
      dump_stack+0xc4/0x118 lib/dump_stack.c:56
      register_lock_class kernel/locking/lockdep.c:792 [inline]
      register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742
      __lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105
      lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599
      __raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline]
      _raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175
      spin_lock_bh include/linux/spinlock.h:307 [inline]
      lock_sock_nested+0x44/0xfa net/core/sock.c:2518
      l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345
      l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598
      l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756
      l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429
      process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064
      worker_thread+0x5a5/0x773 kernel/workqueue.c:2196
      kthread+0x291/0x2a6 kernel/kthread.c:211
      ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com
      Reviewed-by: default avatarAlain Michaud <alainm@chromium.org>
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3af70b39
  8. 22 Mar, 2021 5 commits
    • Arnd Bergmann's avatar
      Bluetooth: fix set_ecdh_privkey() prototype · 8ff0278d
      Arnd Bergmann authored
      gcc-11 points out that the declaration does not match the definition:
      
      net/bluetooth/ecdh_helper.c:122:55: error: argument 2 of type ‘const u8[32]’ {aka ‘const unsigned char[32]’} with mismatched bound [-Werror=array-parameter=]
        122 | int set_ecdh_privkey(struct crypto_kpp *tfm, const u8 private_key[32])
            |                                              ~~~~~~~~~^~~~~~~~~~~~~~~
      In file included from net/bluetooth/ecdh_helper.c:23:
      net/bluetooth/ecdh_helper.h:28:56: note: previously declared as ‘const u8 *’ {aka ‘const unsigned char *’}
         28 | int set_ecdh_privkey(struct crypto_kpp *tfm, const u8 *private_key);
            |                                              ~~~~~~~~~~^~~~~~~~~~~
      
      Change the declaration to contain the size of the array, rather than
      just a pointer.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8ff0278d
    • Tetsuo Handa's avatar
      Bluetooth: initialize skb_queue_head at l2cap_chan_create() · be859723
      Tetsuo Handa authored
      syzbot is hitting "INFO: trying to register non-static key." message [1],
      for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when
      l2cap_chan_del() is called due to e.g. timeout.
      
      Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create()
      immediately after "struct l2cap_chan" is allocated using kzalloc(), let's
      as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there.
      
      [1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842Reported-and-tested-by: default avatarsyzbot <syzbot+fadfba6a911f6bf71842@syzkaller.appspotmail.com>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      be859723
    • Bhaskar Chowdhury's avatar
      Bluetooth: hci_qca: Mundane typo fix · 07528783
      Bhaskar Chowdhury authored
      s/packat/packet/
      Signed-off-by: default avatarBhaskar Chowdhury <unixbhaskar@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      07528783
    • Archie Pusaka's avatar
      Bluetooth: verify AMP hci_chan before amp_destroy · 5c4c8c95
      Archie Pusaka authored
      hci_chan can be created in 2 places: hci_loglink_complete_evt() if
      it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory,
      Only AMP hci_chan should be removed by a call to
      hci_disconn_loglink_complete_evt(). However, the controller might mess
      up, call that function, and destroy an hci_chan which is not initiated
      by hci_loglink_complete_evt().
      
      This patch adds a verification that the destroyed hci_chan must have
      been init'd by hci_loglink_complete_evt().
      
      Example crash call trace:
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xe3/0x144 lib/dump_stack.c:118
       print_address_description+0x67/0x22a mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report mm/kasan/report.c:412 [inline]
       kasan_report+0x251/0x28f mm/kasan/report.c:396
       hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072
       l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877
       l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661
       l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline]
       l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline]
       l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline]
       l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline]
       l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023
       l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596
       hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline]
       hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796
       process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
       worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
       kthread+0x2f0/0x304 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
      
      Allocated by task 38:
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553
       kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787
       kmalloc include/linux/slab.h:515 [inline]
       kzalloc include/linux/slab.h:709 [inline]
       hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674
       l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062
       l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline]
       l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381
       hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404
       hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline]
       hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981
       hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
       process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
       worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
       kthread+0x2f0/0x304 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
      
      Freed by task 1732:
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free mm/kasan/kasan.c:521 [inline]
       __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493
       slab_free_hook mm/slub.c:1409 [inline]
       slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436
       slab_free mm/slub.c:3009 [inline]
       kfree+0x182/0x21e mm/slub.c:3972
       hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline]
       hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050
       hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
       process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
       worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
       kthread+0x2f0/0x304 kernel/kthread.c:253
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
      
      The buggy address belongs to the object at ffff8881d7af9180
       which belongs to the cache kmalloc-128 of size 128
      The buggy address is located 24 bytes inside of
       128-byte region [ffff8881d7af9180, ffff8881d7af9200)
      The buggy address belongs to the page:
      page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0
      flags: 0x8000000000000200(slab)
      raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200
      raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
       ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com
      Reviewed-by: default avatarAlain Michaud <alainm@chromium.org>
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5c4c8c95
    • Archie Pusaka's avatar
      Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default · 3a9d54b1
      Archie Pusaka authored
      Currently l2cap_chan_set_defaults() reset chan->conf_state to zero.
      However, there is a flag CONF_NOT_COMPLETE which is set when
      creating the l2cap_chan. It is suggested that the flag should be
      cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults()
      is called, l2cap_chan is not yet ready. Therefore, we must set this
      flag as the default.
      
      Example crash call trace:
      __dump_stack lib/dump_stack.c:15 [inline]
      dump_stack+0xc4/0x118 lib/dump_stack.c:56
      panic+0x1c6/0x38b kernel/panic.c:117
      __warn+0x170/0x1b9 kernel/panic.c:471
      warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494
      debug_print_object+0x175/0x193 lib/debugobjects.c:260
      debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614
      debug_timer_assert_init kernel/time/timer.c:629 [inline]
      debug_assert_init kernel/time/timer.c:677 [inline]
      del_timer+0x7c/0x179 kernel/time/timer.c:1034
      try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230
      cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929
      l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834
      l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640
      l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756
      l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174
      l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217
      __sock_release+0xda/0x217 net/socket.c:580
      sock_close+0x1b/0x1f net/socket.c:1039
      __fput+0x322/0x55c fs/file_table.c:208
      ____fput+0x17/0x19 fs/file_table.c:244
      task_work_run+0x19b/0x1d3 kernel/task_work.c:115
      exit_task_work include/linux/task_work.h:21 [inline]
      do_exit+0xe4c/0x204a kernel/exit.c:766
      do_group_exit+0x291/0x291 kernel/exit.c:891
      get_signal+0x749/0x1093 kernel/signal.c:2396
      do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737
      exit_to_usermode_loop arch/x86/entry/common.c:243 [inline]
      prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277
      syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348
      int_ret_from_sys_call+0x25/0xa3
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com
      Reviewed-by: default avatarAlain Michaud <alainm@chromium.org>
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarGuenter Roeck <groeck@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3a9d54b1
  9. 18 Mar, 2021 2 commits
  10. 17 Mar, 2021 1 commit
  11. 16 Mar, 2021 1 commit
    • Jiri Kosina's avatar
      Bluetooth: avoid deadlock between hci_dev->lock and socket lock · 17486960
      Jiri Kosina authored
      Commit eab2404b ("Bluetooth: Add BT_PHY socket option") added a
      dependency between socket lock and hci_dev->lock that could lead to
      deadlock.
      
      It turns out that hci_conn_get_phy() is not in any way relying on hdev
      being immutable during the runtime of this function, neither does it even
      look at any of the members of hdev, and as such there is no need to hold
      that lock.
      
      This fixes the lockdep splat below:
      
       ======================================================
       WARNING: possible circular locking dependency detected
       5.12.0-rc1-00026-g73d464503354 #10 Not tainted
       ------------------------------------------------------
       bluetoothd/1118 is trying to acquire lock:
       ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth]
      
       but task is already holding lock:
       ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}:
              lock_sock_nested+0x72/0xa0
              l2cap_sock_ready_cb+0x18/0x70 [bluetooth]
              l2cap_config_rsp+0x27a/0x520 [bluetooth]
              l2cap_sig_channel+0x658/0x1330 [bluetooth]
              l2cap_recv_frame+0x1ba/0x310 [bluetooth]
              hci_rx_work+0x1cc/0x640 [bluetooth]
              process_one_work+0x244/0x5f0
              worker_thread+0x3c/0x380
              kthread+0x13e/0x160
              ret_from_fork+0x22/0x30
      
       -> #2 (&chan->lock#2/1){+.+.}-{3:3}:
              __mutex_lock+0xa3/0xa10
              l2cap_chan_connect+0x33a/0x940 [bluetooth]
              l2cap_sock_connect+0x141/0x2a0 [bluetooth]
              __sys_connect+0x9b/0xc0
              __x64_sys_connect+0x16/0x20
              do_syscall_64+0x33/0x80
              entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       -> #1 (&conn->chan_lock){+.+.}-{3:3}:
              __mutex_lock+0xa3/0xa10
              l2cap_chan_connect+0x322/0x940 [bluetooth]
              l2cap_sock_connect+0x141/0x2a0 [bluetooth]
              __sys_connect+0x9b/0xc0
              __x64_sys_connect+0x16/0x20
              do_syscall_64+0x33/0x80
              entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       -> #0 (&hdev->lock){+.+.}-{3:3}:
              __lock_acquire+0x147a/0x1a50
              lock_acquire+0x277/0x3d0
              __mutex_lock+0xa3/0xa10
              hci_conn_get_phy+0x1c/0x150 [bluetooth]
              l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth]
              __sys_getsockopt+0xcc/0x200
              __x64_sys_getsockopt+0x20/0x30
              do_syscall_64+0x33/0x80
              entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       other info that might help us debug this:
      
       Chain exists of:
         &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                      lock(&chan->lock#2/1);
                                      lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
         lock(&hdev->lock);
      
        *** DEADLOCK ***
      
       1 lock held by bluetoothd/1118:
        #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth]
      
       stack backtrace:
       CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10
       Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
       Call Trace:
        dump_stack+0x7f/0xa1
        check_noncircular+0x105/0x120
        ? __lock_acquire+0x147a/0x1a50
        __lock_acquire+0x147a/0x1a50
        lock_acquire+0x277/0x3d0
        ? hci_conn_get_phy+0x1c/0x150 [bluetooth]
        ? __lock_acquire+0x2e1/0x1a50
        ? lock_is_held_type+0xb4/0x120
        ? hci_conn_get_phy+0x1c/0x150 [bluetooth]
        __mutex_lock+0xa3/0xa10
        ? hci_conn_get_phy+0x1c/0x150 [bluetooth]
        ? lock_acquire+0x277/0x3d0
        ? mark_held_locks+0x49/0x70
        ? mark_held_locks+0x49/0x70
        ? hci_conn_get_phy+0x1c/0x150 [bluetooth]
        hci_conn_get_phy+0x1c/0x150 [bluetooth]
        l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth]
        __sys_getsockopt+0xcc/0x200
        __x64_sys_getsockopt+0x20/0x30
        do_syscall_64+0x33/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7fb73df33eee
       Code: 48 8b 0d 85 0f 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 52 0f 0c 00 f7 d8 64 89 01 48
       RSP: 002b:00007fffcfbbbf08 EFLAGS: 00000203 ORIG_RAX: 0000000000000037
       RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007fb73df33eee
       RDX: 000000000000000e RSI: 0000000000000112 RDI: 0000000000000018
       RBP: 0000000000000000 R08: 00007fffcfbbbf44 R09: 0000000000000000
       R10: 00007fffcfbbbf3c R11: 0000000000000203 R12: 0000000000000000
       R13: 0000000000000018 R14: 0000000000000000 R15: 0000556fcefc70d0
      
      Fixes: eab2404b ("Bluetooth: Add BT_PHY socket option")
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      17486960
  12. 15 Mar, 2021 1 commit