1. 28 Feb, 2020 2 commits
    • Madhuparna Bhowmik's avatar
      Bluetooth: Fix Suspicious RCU usage warnings · d7d41682
      Madhuparna Bhowmik authored
      The following functions in hci_core are always called with
      hdev->lock held. No need to use list_for_each_entry_rcu(), therefore
      change the usage of list_for_each_entry_rcu() in these functions
      to list_for_each_entry().
      
      hci_link_keys_clear()
      hci_smp_ltks_clear()
      hci_smp_irks_clear()
      hci_blocked_keys_clear()
      
      Warning encountered with CONFIG_PROVE_RCU_LIST:
      
      [   72.213184] =============================
      [   72.213188] WARNING: suspicious RCU usage
      [   72.213192] 5.6.0-rc1+ #5 Not tainted
      [   72.213195] -----------------------------
      [   72.213198] net/bluetooth/hci_core.c:2288 RCU-list traversed in non-reader section!!
      
      [   72.213676] =============================
      [   72.213679] WARNING: suspicious RCU usage
      [   72.213683] 5.6.0-rc1+ #5 Not tainted
      [   72.213685] -----------------------------
      [   72.213689] net/bluetooth/hci_core.c:2298 RCU-list traversed in non-reader section!!
      
      [   72.214195] =============================
      [   72.214198] WARNING: suspicious RCU usage
      [   72.214201] 5.6.0-rc1+ #5 Not tainted
      [   72.214204] -----------------------------
      [   72.214208] net/bluetooth/hci_core.c:2308 RCU-list traversed in non-reader section!!
      
      [  333.456972] =============================
      [  333.456979] WARNING: suspicious RCU usage
      [  333.457001] 5.6.0-rc1+ #5 Not tainted
      [  333.457007] -----------------------------
      [  333.457014] net/bluetooth/hci_core.c:2318 RCU-list traversed in non-reader section!!
      Signed-off-by: default avatarMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d7d41682
    • Gustavo A. R. Silva's avatar
      Bluetooth: Replace zero-length array with flexible-array member · a7e45454
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a7e45454
  2. 19 Feb, 2020 2 commits
  3. 18 Feb, 2020 5 commits
  4. 16 Feb, 2020 1 commit
  5. 14 Feb, 2020 2 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Add BT_PHY socket option · eab2404b
      Luiz Augusto von Dentz authored
      This adds BT_PHY socket option (read-only) which can be used to read
      the PHYs in use by the underline connection.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      eab2404b
    • Howard Chung's avatar
      Bluetooth: secure bluetooth stack from bluedump attack · cee5f20f
      Howard Chung authored
      Attack scenario:
      1. A Chromebook (let's call this device A) is paired to a legitimate
         Bluetooth classic device (e.g. a speaker) (let's call this device
         B).
      2. A malicious device (let's call this device C) pretends to be the
         Bluetooth speaker by using the same BT address.
      3. If device A is not currently connected to device B, device A will
         be ready to accept connection from device B in the background
         (technically, doing Page Scan).
      4. Therefore, device C can initiate connection to device A
         (because device A is doing Page Scan) and device A will accept the
         connection because device A trusts device C's address which is the
         same as device B's address.
      5. Device C won't be able to communicate at any high level Bluetooth
         profile with device A because device A enforces that device C is
         encrypted with their common Link Key, which device C doesn't have.
         But device C can initiate pairing with device A with just-works
         model without requiring user interaction (there is only pairing
         notification). After pairing, device A now trusts device C with a
         new different link key, common between device A and C.
      6. From now on, device A trusts device C, so device C can at anytime
         connect to device A to do any kind of high-level hijacking, e.g.
         speaker hijack or mouse/keyboard hijack.
      
      Since we don't know whether the repairing is legitimate or not,
      leave the decision to user space if all the conditions below are met.
      - the pairing is initialized by peer
      - the authorization method is just-work
      - host already had the link key to the peer
      Signed-off-by: default avatarHoward Chung <howardchung@google.com>
      Acked-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cee5f20f
  6. 13 Feb, 2020 3 commits
  7. 08 Feb, 2020 1 commit
    • Sergey Shatunov's avatar
      Bluetooth: btusb: Add support for 13d3:3548 Realtek 8822CE device · eb3939e3
      Sergey Shatunov authored
      The ASUS FX505DV laptop contains RTL8822CE device with an
      associated BT chip using a USB ID of 13d3:3548.
      This patch add fw download support for it.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#=  4 Spd=12   MxCh= 0
      D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3548 Rev= 0.00
      S:  Manufacturer=Realtek
      S:  Product=Bluetooth Radio
      S:  SerialNumber=00e04c000001
      C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarSergey Shatunov <me@prok.pw>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      eb3939e3
  8. 05 Feb, 2020 3 commits
  9. 03 Feb, 2020 2 commits
  10. 29 Jan, 2020 2 commits
    • Davidlohr Bueso's avatar
      Bluetooth: optimize barrier usage for Rmw atomics · fe664831
      Davidlohr Bueso authored
      Use smp_mb__before_atomic() instead of smp_mb() and avoid the
      unnecessary barrier for non LL/SC architectures, such as x86.
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      fe664831
    • Manish Mandlik's avatar
      Bluetooth: Fix refcount use-after-free issue · 6c08fc89
      Manish Mandlik authored
      There is no lock preventing both l2cap_sock_release() and
      chan->ops->close() from running at the same time.
      
      If we consider Thread A running l2cap_chan_timeout() and Thread B running
      l2cap_sock_release(), expected behavior is:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
      
      where,
      sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks
      socket as SOCK_ZAPPED.
      
      In l2cap_sock_kill(), there is an "if-statement" that checks if both
      sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL
      and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is
      satisfied.
      
      In the race condition, following occurs:
        A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        B::l2cap_sock_release()->sock_orphan()
        B::l2cap_sock_release()->l2cap_sock_kill()
        A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
      In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and
      A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug.
      
      Similar condition occurs at other places where teardown/sock_kill is
      happening:
        l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb()
        l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill()
      
        l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb()
        l2cap_sock_cleanup_listen()->l2cap_sock_kill()
      
      Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on
      l2cap channel to ensure that the socket is killed only after marked as
      zapped and orphan.
      Signed-off-by: default avatarManish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6c08fc89
  11. 28 Jan, 2020 1 commit
  12. 27 Jan, 2020 16 commits