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. 22 Oct, 2015 1 commit
    • 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
  3. 16 Mar, 2015 1 commit
  4. 30 Dec, 2014 1 commit
  5. 03 Dec, 2014 4 commits
  6. 15 Nov, 2014 1 commit
  7. 11 Sep, 2014 1 commit
  8. 08 Sep, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Add strict checks for allowed SMP PDUs · b28b4943
      Johan Hedberg authored
      SMP defines quite clearly when certain PDUs are to be expected/allowed
      and when not, but doesn't have any explicit request/response definition.
      So far the code has relied on each PDU handler to behave correctly if
      receiving PDUs at an unexpected moment, however this requires many
      different checks and is prone to errors.
      
      This patch introduces a generic way to keep track of allowed PDUs and
      thereby reduces the responsibility & load on individual command
      handlers. The tracking is implemented using a simple bit-mask where each
      opcode maps to its own bit. If the bit is set the corresponding PDU is
      allow and if the bit is not set the PDU is not allowed.
      
      As a simple example, when we send the Pairing Request we'd set the bit
      for Pairing Response, and when we receive the Pairing Response we'd
      clear the bit for Pairing Response.
      
      Since the disallowed PDU rejection is now done in a single central place
      we need to be a bit careful of which action makes most sense to all
      cases. Previously some, such as Security Request, have been simply
      ignored whereas others have caused an explicit disconnect.
      
      The only PDU rejection action that keeps good interoperability and can
      be used for all the applicable use cases is to drop the data. This may
      raise some concerns of us now being more lenient for misbehaving (and
      potentially malicious) devices, but the policy of simply dropping data
      has been a successful one for many years e.g. in L2CAP (where this is
      the *only* policy for such cases - we never request disconnection in
      l2cap_core.c because of bad data). Furthermore, we cannot prevent
      connected devices from creating the SMP context (through a Security or
      Pairing Request), and once the context exists looking up the
      corresponding bit for the received opcode and deciding to reject it is
      essentially an equally lightweight operation as the kind of rejection
      that l2cap_core.c already successfully does.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b28b4943
  9. 14 Aug, 2014 5 commits
  10. 03 Jul, 2014 1 commit
  11. 20 May, 2014 1 commit
  12. 08 May, 2014 1 commit
  13. 24 Mar, 2014 2 commits
  14. 19 Mar, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Increase SMP re-encryption delay to 500ms · 5ed884d7
      Johan Hedberg authored
      In some cases the current 250ms delay is not enough for the remote to
      receive the keys, as can be witnessed by the following log:
      
      > ACL Data RX: Handle 64 flags 0x02 dlen 21               [hci1] 231.414217
            SMP: Signing Information (0x0a) len 16
              Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414414
            SMP: Encryption Information (0x06) len 16
              Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29
      < ACL Data TX: Handle 64 flags 0x00 dlen 15               [hci1] 231.414466
            SMP: Master Identification (0x07) len 10
              EDIV: 0xeccc
              Rand: 0x322e0ef50bd9308a
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414505
            SMP: Signing Information (0x0a) len 16
              Signature key: bbda1b2076e2325aa66fbcdd5388f745
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.483130
              Num handles: 1
              Handle: 64
              Count: 2
      < HCI Command: LE Start Encryption (0x08|0x0019) plen 28  [hci1] 231.664211
              Handle: 64
              Random number: 0x5052ad2b75fed54b
              Encrypted diversifier: 0xb7c2
              Long term key: a336ede66711b49a84bde9b41426692e
      > HCI Event: Command Status (0x0f) plen 4                 [hci1] 231.666937
            LE Start Encryption (0x08|0x0019) ncmd 1
              Status: Success (0x00)
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.712646
              Num handles: 1
              Handle: 64
              Count: 1
      > HCI Event: Disconnect Complete (0x05) plen 4            [hci1] 232.562587
              Status: Success (0x00)
              Handle: 64
              Reason: Remote User Terminated Connection (0x13)
      
      As can be seen, the last key (Signing Information) is sent at 231.414505
      but the completed packets event for it comes only at 231.712646,
      i.e. roughly 298ms later.
      
      To have a better margin of error this patch increases the delay to
      500ms.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5ed884d7
  15. 09 Mar, 2014 1 commit
  16. 28 Feb, 2014 3 commits
  17. 26 Feb, 2014 1 commit
  18. 23 Feb, 2014 1 commit
  19. 19 Feb, 2014 1 commit
  20. 18 Feb, 2014 5 commits
  21. 05 Dec, 2013 1 commit
  22. 10 Oct, 2013 1 commit
  23. 27 Aug, 2012 1 commit
  24. 06 Aug, 2012 1 commit
  25. 09 May, 2012 1 commit
  26. 13 Feb, 2012 1 commit