1. 28 Jul, 2020 5 commits
    • Abhishek Pandit-Subedi's avatar
      Bluetooth: Fix suspend notifier race · 4e8c36c3
      Abhishek Pandit-Subedi authored
      Unregister from suspend notifications and cancel suspend preparations
      before running hci_dev_do_close. Otherwise, the suspend notifier may
      race with unregister and cause cmd_timeout even after hdev has been
      freed.
      
      Below is the trace from when this panic was seen:
      
      [  832.578518] Bluetooth: hci_core.c:hci_cmd_timeout() hci0: command 0x0c05 tx timeout
      [  832.586200] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [  832.586203] #PF: supervisor read access in kernel mode
      [  832.586205] #PF: error_code(0x0000) - not-present page
      [  832.586206] PGD 0 P4D 0
      [  832.586210] PM: suspend exit
      [  832.608870] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [  832.613232] CPU: 3 PID: 10755 Comm: kworker/3:7 Not tainted 5.4.44-04894-g1e9dbb96a161 #1
      [  832.630036] Workqueue: events hci_cmd_timeout [bluetooth]
      [  832.630046] RIP: 0010:__queue_work+0xf0/0x374
      [  832.630051] RSP: 0018:ffff9b5285f1fdf8 EFLAGS: 00010046
      [  832.674033] RAX: ffff8a97681bac00 RBX: 0000000000000000 RCX: ffff8a976a000600
      [  832.681162] RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff8a976a000748
      [  832.688289] RBP: ffff9b5285f1fe38 R08: 0000000000000000 R09: ffff8a97681bac00
      [  832.695418] R10: 0000000000000002 R11: ffff8a976a0006d8 R12: ffff8a9745107600
      [  832.698045] usb 1-6: new full-speed USB device number 119 using xhci_hcd
      [  832.702547] R13: ffff8a9673658850 R14: 0000000000000040 R15: 000000000000001e
      [  832.702549] FS:  0000000000000000(0000) GS:ffff8a976af80000(0000) knlGS:0000000000000000
      [  832.702550] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  832.702550] CR2: 0000000000000000 CR3: 000000010415a000 CR4: 00000000003406e0
      [  832.702551] Call Trace:
      [  832.702558]  queue_work_on+0x3f/0x68
      [  832.702562]  process_one_work+0x1db/0x396
      [  832.747397]  worker_thread+0x216/0x375
      [  832.751147]  kthread+0x138/0x140
      [  832.754377]  ? pr_cont_work+0x58/0x58
      [  832.758037]  ? kthread_blkcg+0x2e/0x2e
      [  832.761787]  ret_from_fork+0x22/0x40
      [  832.846191] ---[ end trace fa93f466da517212 ]---
      
      Fixes: 9952d90e ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND")
      Signed-off-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarMiao-chen Chou <mcchou@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4e8c36c3
    • Nicolas Boichat's avatar
      Bluetooth: hci_serdev: Only unregister device if it was registered · 202798db
      Nicolas Boichat authored
      We should not call hci_unregister_dev if the device was not
      successfully registered.
      
      Fixes: c34dc3bf ("Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()")
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      202798db
    • Max Chou's avatar
      Bluetooth: Return NOTIFY_DONE for hci_suspend_notifier · 24b06572
      Max Chou authored
      The original return is NOTIFY_STOP, but notifier_call_chain would stop
      the future call for register_pm_notifier even registered on other Kernel
      modules with the same priority which value is zero.
      Signed-off-by: default avatarMax Chou <max.chou@realtek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      24b06572
    • Nicolas Boichat's avatar
      Bluetooth: hci_h5: Set HCI_UART_RESET_ON_INIT to correct flags · a7ad4b61
      Nicolas Boichat authored
      HCI_UART_RESET_ON_INIT belongs in hdev_flags, not flags.
      
      Fixes: ce945552 ("Bluetooth: hci_h5: Add support for serdev enumerated devices")
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a7ad4b61
    • Ismael Ferreras Morezuelas's avatar
      Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers · cde1a8a9
      Ismael Ferreras Morezuelas authored
      For some reason they tend to squat on the very first CSR/
      Cambridge Silicon Radio VID/PID instead of paying fees.
      
      This is an extremely common problem; the issue goes as back as 2013
      and these devices are only getting more popular, even rebranded by
      reputable vendors and sold by retailers everywhere.
      
      So, at this point in time there are hundreds of modern dongles reusing
      the ID of what originally was an early Bluetooth 1.1 controller.
      
      Linux is the only place where they don't work due to spotty checks
      in our detection code. It only covered a minimum subset.
      
      So what's the big idea? Take advantage of the fact that all CSR
      chips report the same internal version as both the LMP sub-version and
      HCI revision number. It always matches, couple that with the manufacturer
      code, that rarely lies, and we now have a good idea of who is who.
      
      Additionally, by compiling a list of user-reported HCI/lsusb dumps, and
      searching around for legit CSR dongles in similar product ranges we can
      find what CSR BlueCore firmware supported which Bluetooth versions.
      
      That way we can narrow down ranges of fakes for each of them.
      
      e.g. Real CSR dongles with LMP subversion 0x73 are old enough that
           support BT 1.1 only; so it's a dead giveaway when some
           third-party BT 4.0 dongle reuses it.
      
      So, to sum things up; there are multiple classes of fake controllers
      reusing the same 0A12:0001 VID/PID. This has been broken for a while.
      
      Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891
        IC markings on 0x7558: FR3191AHAL 749H15143 (???)
      
      https://bugzilla.kernel.org/show_bug.cgi?id=60824
      
      Fixes: 81cac64b (Deal with USB devices that are faking CSR vendor)
      Reported-by: default avatarMichał Wiśniewski <brylozketrzyn@gmail.com>
      Tested-by: default avatarMike Johnson <yuyuyak@gmail.com>
      Tested-by: default avatarRicardo Rodrigues <ekatonb@gmail.com>
      Tested-by: default avatarM.Hanny Sabbagh <mhsabbagh@outlook.com>
      Tested-by: default avatarOussama BEN BRAHIM <b.brahim.oussama@gmail.com>
      Tested-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cde1a8a9
  2. 16 Jul, 2020 1 commit
    • Patrick Steinhardt's avatar
      Bluetooth: Fix update of connection state in `hci_encrypt_cfm` · 339ddaa6
      Patrick Steinhardt authored
      Starting with the upgrade to v5.8-rc3, I've noticed I wasn't able to
      connect to my Bluetooth headset properly anymore. While connecting to
      the device would eventually succeed, bluetoothd seemed to be confused
      about the current connection state where the state was flapping hence
      and forth. Bisecting this issue led to commit 3ca44c16 (Bluetooth:
      Consolidate encryption handling in hci_encrypt_cfm, 2020-05-19), which
      refactored `hci_encrypt_cfm` to also handle updating the connection
      state.
      
      The commit in question changed the code to call `hci_connect_cfm` inside
      `hci_encrypt_cfm` and to change the connection state. But with the
      conversion, we now only update the connection state if a status was set
      already. In fact, the reverse should be true: the status should be
      updated if no status is yet set. So let's fix the isuse by reversing the
      condition.
      
      Fixes: 3ca44c16 ("Bluetooth: Consolidate encryption handling in hci_encrypt_cfm")
      Signed-off-by: default avatarPatrick Steinhardt <ps@pks.im>
      Acked-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      339ddaa6
  3. 15 Jul, 2020 1 commit
  4. 13 Jul, 2020 4 commits
  5. 10 Jul, 2020 5 commits
  6. 08 Jul, 2020 1 commit
  7. 07 Jul, 2020 6 commits
  8. 26 Jun, 2020 1 commit
  9. 25 Jun, 2020 1 commit
  10. 24 Jun, 2020 3 commits
  11. 23 Jun, 2020 3 commits
    • Sean Wang's avatar
      Bluetooth: btmtksdio: fix up firmware download sequence · 737cd060
      Sean Wang authored
      Data RAM on the device have to be powered on before starting to download
      the firmware.
      
      Fixes: 9aebfd4a ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices")
      Co-developed-by: default avatarMark Chen <Mark-YW.Chen@mediatek.com>
      Signed-off-by: default avatarMark Chen <Mark-YW.Chen@mediatek.com>
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      737cd060
    • Sean Wang's avatar
      Bluetooth: btusb: fix up firmware download sequence · f6451257
      Sean Wang authored
      Data RAM on the device have to be powered on before starting to download
      the firmware.
      
      Fixes: a1c49c43 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
      Co-developed-by: default avatarMark Chen <Mark-YW.Chen@mediatek.com>
      Signed-off-by: default avatarMark Chen <Mark-YW.Chen@mediatek.com>
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f6451257
    • Lihong Kou's avatar
      Bluetooth: add a mutex lock to avoid UAF in do_enale_set · f9c70bdc
      Lihong Kou authored
      In the case we set or free the global value listen_chan in
      different threads, we can encounter the UAF problems because
      the method is not protected by any lock, add one to avoid
      this bug.
      
      BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990
      net/bluetooth/l2cap_core.c:730
      Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868
      
      CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine,
      BIOS Google 01/01/2011
      Workqueue: events do_enable_set
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1fb/0x318 lib/dump_stack.c:118
       print_address_description+0x74/0x5c0 mm/kasan/report.c:374
       __kasan_report+0x149/0x1c0 mm/kasan/report.c:506
       kasan_report+0x26/0x50 mm/kasan/common.c:641
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
       l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730
       do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074
       process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
       worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
       kthread+0x332/0x350 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Allocated by task 2870:
       save_stack mm/kasan/common.c:72 [inline]
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
       kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446
       chan_create net/bluetooth/6lowpan.c:640 [inline]
       bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline]
       do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078
       process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
       worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
       kthread+0x332/0x350 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Freed by task 2870:
       save_stack mm/kasan/common.c:72 [inline]
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:337 [inline]
       __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x10d/0x220 mm/slab.c:3757
       l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline]
       kref_put include/linux/kref.h:65 [inline]
       l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498
       do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075
       process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
       worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
       kthread+0x332/0x350 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff888096950000
       which belongs to the cache kmalloc-2k of size 2048
      The buggy address is located 0 bytes inside of
       2048-byte region [ffff888096950000, ffff888096950800)
      The buggy address belongs to the page:
      page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00
      raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com
      Signed-off-by: default avatarLihong Kou <koulihong@huawei.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f9c70bdc
  12. 22 Jun, 2020 3 commits
  13. 18 Jun, 2020 6 commits