1. 10 Nov, 2018 1 commit
    • Matias Karhumaa's avatar
      Bluetooth: SMP: fix crash in unpairing · b0c52fbf
      Matias Karhumaa authored
      [ Upstream commit cb28c306b93b71f2741ce1a5a66289db26715f4d ]
      
      In case unpair_device() was called through mgmt interface at the same time
      when pairing was in progress, Bluetooth kernel module crash was seen.
      
      [  600.351225] general protection fault: 0000 [#1] SMP PTI
      [  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G           OE     4.19.0-rc1+ #1
      [  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
      [  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351295] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351298] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      [  600.351302] Call Trace:
      [  600.351325]  smp_failure+0x4f/0x70 [bluetooth]
      [  600.351345]  smp_cancel_pairing+0x74/0x80 [bluetooth]
      [  600.351370]  unpair_device+0x1c1/0x330 [bluetooth]
      [  600.351399]  hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
      [  600.351409]  ? apparmor_socket_sendmsg+0x1e/0x20
      [  600.351417]  sock_sendmsg+0x3e/0x50
      [  600.351422]  sock_write_iter+0x85/0xf0
      [  600.351429]  do_iter_readv_writev+0x12b/0x1b0
      [  600.351434]  do_iter_write+0x87/0x1a0
      [  600.351439]  vfs_writev+0x98/0x110
      [  600.351443]  ? ep_poll+0x16d/0x3d0
      [  600.351447]  ? ep_modify+0x73/0x170
      [  600.351451]  do_writev+0x61/0xf0
      [  600.351455]  ? do_writev+0x61/0xf0
      [  600.351460]  __x64_sys_writev+0x1c/0x20
      [  600.351465]  do_syscall_64+0x5a/0x110
      [  600.351471]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  600.351474] RIP: 0033:0x7fb2bdb62fe0
      [  600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
      [  600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      [  600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0
      [  600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004
      [  600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000
      [  600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001
      [  600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000
      [  600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
      [  600.351569]  snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
      [  600.351637] ---[ end trace e49e9f1df09c94fb ]---
      [  600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
      [  600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
      [  600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246
      [  600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60
      [  600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500
      [  600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00
      [  600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800
      [  600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00
      [  600.351684] FS:  00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000
      [  600.351686] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0
      
      Crash happened because list_del_rcu() was called twice for smp->ltk. This
      was possible if unpair_device was called right after ltk was generated
      but before keys were distributed.
      
      In this commit smp_cancel_pairing was refactored to cancel pairing if it
      is in progress and otherwise just removes keys. Once keys are removed from
      rcu list, pointers to smp context's keys are set to NULL to make sure
      removed list items are not accessed later.
      
      This commit also adjusts the functionality of mgmt unpair_device() little
      bit. Previously pairing was canceled only if pairing was in state that
      keys were already generated. With this commit unpair_device() cancels
      pairing already in earlier states.
      
      Bug was found by fuzzing kernel SMP implementation using Synopsys
      Defensics.
      Reported-by: default avatarPekka Oikarainen <pekka.oikarainen@synopsys.com>
      Signed-off-by: default avatarMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b0c52fbf
  2. 12 Apr, 2016 1 commit
  3. 22 Oct, 2015 3 commits
    • Johan Hedberg's avatar
      Bluetooth: Take advantage of connection abort helpers · 89e0ccc8
      Johan Hedberg authored
      Convert the various places mapping connection state to
      disconnect/cancel HCI command to use the new hci_abort_conn helper
      API.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      89e0ccc8
    • Johan Hedberg's avatar
      Bluetooth: Fix crash in SMP when unpairing · c81d555a
      Johan Hedberg authored
      When unpairing the keys stored in hci_dev are removed. If SMP is
      ongoing the SMP context will also have references to these keys, so
      removing them from the hci_dev lists will make the pointers invalid.
      This can result in the following type of crashes:
      
       BUG: unable to handle kernel paging request at 6b6b6b6b
       IP: [<c11f26be>] __list_del_entry+0x44/0x71
       *pde = 00000000
       Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in: hci_uart btqca btusb btintel btbcm btrtl hci_vhci rfcomm bluetooth_6lowpan bluetooth
       CPU: 0 PID: 723 Comm: kworker/u5:0 Not tainted 4.3.0-rc3+ #1379
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
       Workqueue: hci0 hci_rx_work [bluetooth]
       task: f19da940 ti: f1a94000 task.ti: f1a94000
       EIP: 0060:[<c11f26be>] EFLAGS: 00010202 CPU: 0
       EIP is at __list_del_entry+0x44/0x71
       EAX: c0088d20 EBX: f30fcac0 ECX: 6b6b6b6b EDX: 6b6b6b6b
       ESI: f4b60000 EDI: c0088d20 EBP: f1a95d90 ESP: f1a95d8c
        DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
       CR0: 8005003b CR2: 6b6b6b6b CR3: 319e5000 CR4: 00000690
       Stack:
        f30fcac0 f1a95db0 f82dc3e1 f1bfc000 00000000 c106524f f1bfc000 f30fd020
        f1a95dc0 f1a95dd0 f82dcbdb f1a95de0 f82dcbdb 00000067 f1bfc000 f30fd020
        f1a95de0 f1a95df0 f82d1126 00000067 f82d1126 00000006 f30fd020 f1bfc000
       Call Trace:
        [<f82dc3e1>] smp_chan_destroy+0x192/0x240 [bluetooth]
        [<c106524f>] ? trace_hardirqs_on_caller+0x14e/0x169
        [<f82dcbdb>] smp_teardown_cb+0x47/0x64 [bluetooth]
        [<f82dcbdb>] ? smp_teardown_cb+0x47/0x64 [bluetooth]
        [<f82d1126>] l2cap_chan_del+0x5d/0x14d [bluetooth]
        [<f82d1126>] ? l2cap_chan_del+0x5d/0x14d [bluetooth]
        [<f82d40ef>] l2cap_conn_del+0x109/0x17b [bluetooth]
        [<f82d40ef>] ? l2cap_conn_del+0x109/0x17b [bluetooth]
        [<f82c0205>] ? hci_event_packet+0x5b1/0x2092 [bluetooth]
        [<f82d41aa>] l2cap_disconn_cfm+0x49/0x50 [bluetooth]
        [<f82d41aa>] ? l2cap_disconn_cfm+0x49/0x50 [bluetooth]
        [<f82c0228>] hci_event_packet+0x5d4/0x2092 [bluetooth]
        [<c1332c16>] ? skb_release_data+0x6a/0x95
        [<f82ce5d4>] ? hci_send_to_monitor+0xe7/0xf4 [bluetooth]
        [<c1409708>] ? _raw_spin_unlock_irqrestore+0x44/0x57
        [<f82b3bb0>] hci_rx_work+0xf1/0x28b [bluetooth]
        [<f82b3bb0>] ? hci_rx_work+0xf1/0x28b [bluetooth]
        [<c10635a0>] ? __lock_is_held+0x2e/0x44
        [<c104772e>] process_one_work+0x232/0x432
        [<c1071ddc>] ? rcu_read_lock_sched_held+0x50/0x5a
        [<c104772e>] ? process_one_work+0x232/0x432
        [<c1047d48>] worker_thread+0x1b8/0x255
        [<c1047b90>] ? rescuer_thread+0x23c/0x23c
        [<c104bb71>] kthread+0x91/0x96
        [<c14096a7>] ? _raw_spin_unlock_irq+0x27/0x44
        [<c1409d61>] ret_from_kernel_thread+0x21/0x30
        [<c104bae0>] ? kthread_parkme+0x1e/0x1e
      
      To solve the issue, introduce a new smp_cancel_pairing() API that can
      be used to clean up the SMP state before touching the hci_dev lists.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c81d555a
    • Johan Hedberg's avatar
      Bluetooth: Disable auto-connection parameters when unpairing · fc64361a
      Johan Hedberg authored
      For connection parameters that are left around until a disconnection
      we should at least clear any auto-connection properties. This way a
      new Add Device call is required to re-set them after calling Unpair
      Device.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      fc64361a
  4. 21 Oct, 2015 3 commits
  5. 20 Oct, 2015 2 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix removing connection parameters when unpairing · a6ad2a6b
      Johan Hedberg authored
      The commit 89cbb063 introduced support for deferred connection
      parameter removal when unpairing by removing them only once an
      existing connection gets disconnected. However, it failed to address
      the scenario when we're *not* connected and do an unpair operation.
      
      What makes things worse is that most user space BlueZ versions will
      first issue a disconnect request and only then unpair, meaning the
      buggy code will be triggered every time. This effectively causes the
      kernel to resume scanning and reconnect to a device for which we've
      removed all keys and GATT database information.
      
      This patch fixes the issue by adding the missing call to the
      hci_conn_params_del() function to a branch which handles the case of
      no existing connection.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org # 3.19+
      a6ad2a6b
    • Johan Hedberg's avatar
      Bluetooth: Don't use remote address type to decide IRK persistency · cad20c27
      Johan Hedberg authored
      There are LE devices on the market that start off by announcing their
      public address and then once paired switch to using private address.
      To be interoperable with such devices we should simply trust the fact
      that we're receiving an IRK from them to indicate that they may use
      private addresses in the future. Instead, simply tie the persistency
      to the bonding/no-bonding information the same way as for LTKs and
      CSRKs.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cad20c27
  6. 16 Oct, 2015 4 commits
  7. 10 Aug, 2015 3 commits
    • Jakub Pawlowski's avatar
      Bluetooth: Enable new connection establishment procedure. · fa142220
      Jakub Pawlowski authored
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This patch enables new connection establishment procedure. Instead of just
      sending HCI_OP_LE_CREATE_CONN to controller, "connect" will add device to
      kernel whitelist and start scan. If advertisement is received, it'll be
      compared against whitelist and then trigger connection if it matches.
      That fixes mentioned reconnect issue for  already paired devices. It also
      make whole connection procedure more robust. We can try to connect to
      multiple devices at same time now, even though controller allow only one.
      Signed-off-by: default avatarJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      fa142220
    • Jakub Pawlowski's avatar
      Bluetooth: advertisement handling in new connect procedure · 28a667c9
      Jakub Pawlowski authored
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This path makes sure that after advertisement is received from device that
      we try to connect to, it is properly handled in check_pending_le_conn and
      trigger connect attempt.
      
      It also modifies hci_le_connect to make sure that connect attempt will be
      properly continued.
      Signed-off-by: default avatarJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      28a667c9
    • Jakub Pawlowski's avatar
      Bluetooth: add hci_lookup_le_connect · e7d9ab73
      Jakub Pawlowski authored
      This patch adds hci_lookup_le_connect method, that will be used to check
      wether outgoing le connection attempt is in progress.
      Signed-off-by: default avatarJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e7d9ab73
  8. 06 Aug, 2015 1 commit
    • Jakub Pawlowski's avatar
      Bluetooth: fix MGMT_EV_NEW_LONG_TERM_KEY event · cb92205b
      Jakub Pawlowski authored
      This patch fixes how MGMT_EV_NEW_LONG_TERM_KEY event is build. Right now
      val vield is filled with only 1 byte, instead of whole value. This bug
      was introduced in
      commit 1fc62c52 ("Bluetooth: Fix exposing full value of shortened LTKs")
      
      Before that patch, if you paired with device using bluetoothd using simple
      pairing, and then restarted bluetoothd, you would be able to re-connect,
      but device would fail to establish encryption and would terminate
      connection. After this patch connecting after bluetoothd restart works
      fine.
      Signed-off-by: default avatarJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cb92205b
  9. 23 Jul, 2015 1 commit
  10. 18 Jun, 2015 20 commits
  11. 10 Jun, 2015 1 commit