1. 30 Jul, 2020 6 commits
  2. 28 Jul, 2020 6 commits
  3. 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
  4. 15 Jul, 2020 1 commit
  5. 13 Jul, 2020 4 commits
  6. 10 Jul, 2020 5 commits
  7. 08 Jul, 2020 1 commit
  8. 07 Jul, 2020 6 commits
  9. 26 Jun, 2020 1 commit
  10. 25 Jun, 2020 1 commit
  11. 24 Jun, 2020 3 commits
  12. 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
  13. 22 Jun, 2020 2 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Disconnect if E0 is used for Level 4 · 8746f135
      Luiz Augusto von Dentz authored
      E0 is not allowed with Level 4:
      
      BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C page 1319:
      
        '128-bit equivalent strength for link and encryption keys
         required using FIPS approved algorithms (E0 not allowed,
         SAFER+ not allowed, and P-192 not allowed; encryption key
         not shortened'
      
      SC enabled:
      
      > HCI Event: Read Remote Extended Features (0x23) plen 13
              Status: Success (0x00)
              Handle: 256
              Page: 1/2
              Features: 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                Secure Simple Pairing (Host Support)
                LE Supported (Host)
                Secure Connections (Host Support)
      > HCI Event: Encryption Change (0x08) plen 4
              Status: Success (0x00)
              Handle: 256
              Encryption: Enabled with AES-CCM (0x02)
      
      SC disabled:
      
      > HCI Event: Read Remote Extended Features (0x23) plen 13
              Status: Success (0x00)
              Handle: 256
              Page: 1/2
              Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                Secure Simple Pairing (Host Support)
                LE Supported (Host)
      > HCI Event: Encryption Change (0x08) plen 4
              Status: Success (0x00)
              Handle: 256
              Encryption: Enabled with E0 (0x01)
      [May 8 20:23] Bluetooth: hci0: Invalid security: expect AES but E0 was used
      < HCI Command: Disconnect (0x01|0x0006) plen 3
              Handle: 256
              Reason: Authentication Failure (0x05)
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8746f135
    • Alain Michaud's avatar
      Bluetooth: use configured params for ext adv · 5cbd3ebd
      Alain Michaud authored
      When the extended advertisement feature is enabled, a hardcoded min and
      max interval of 0x8000 is used.  This patch fixes this issue by using
      the configured min/max value.
      
      This was validated by setting min/max in main.conf and making sure the
      right setting is applied:
      
      < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen
      25                                          #93 [hci0] 10.953011
      …
      Min advertising interval: 181.250 msec (0x0122)
      Max advertising interval: 181.250 msec (0x0122)
      …
      Signed-off-by: default avatarAlain Michaud <alainm@chromium.org>
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarDaniel Winkler <danielwinkler@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5cbd3ebd