1. 19 2月, 2014 5 次提交
  2. 18 2月, 2014 5 次提交
  3. 13 2月, 2014 2 次提交
    • J
      Bluetooth: Fix differentiating stored master vs slave LTK types · 98a0b845
      Johan Hedberg 提交于
      If LTK distribution happens in both directions we will have two LTKs for
      the same remote device: one which is used when we're connecting as
      master and another when we're connecting as slave. When looking up LTKs
      from the locally stored list we shouldn't blindly return the first match
      but also consider which type of key is in question. If we do not do this
      we may end up selecting an incorrect encryption key for a connection.
      
      This patch fixes the issue by always specifying to the LTK lookup
      functions whether we're looking for a master or a slave key.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      98a0b845
    • J
      Bluetooth: Enable LTK distribution to slave devices · 0cf73b9f
      Johan Hedberg 提交于
      So far we've only been requesting the LTK to be distributed to the
      master (initiator) of pairing, which is usually enough since it's the
      master that will establish future connections and initiate encryption.
      However, in the case that both devices support switching to the opposing
      role (which seems to be increasingly common) pairing will have to
      performed again since the "new" master will not have all information.
      
      As there is no real harm in it, this patch updates the code to always
      try distributing the LTK also to the slave device, thereby enabling role
      switches for future connections.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: NVinicius Gomes <vcgomes@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0cf73b9f
  4. 05 12月, 2013 1 次提交
  5. 04 12月, 2013 3 次提交
  6. 13 11月, 2013 1 次提交
  7. 18 10月, 2013 1 次提交
  8. 16 10月, 2013 1 次提交
  9. 13 10月, 2013 4 次提交
  10. 11 10月, 2013 1 次提交
  11. 03 10月, 2013 2 次提交
  12. 12 6月, 2013 1 次提交
  13. 12 4月, 2013 1 次提交
    • D
      Bluetooth: rename hci_conn_put to hci_conn_drop · 76a68ba0
      David Herrmann 提交于
      We use _get() and _put() for device ref-counting in the kernel. However,
      hci_conn_put() is _not_ used for ref-counting, hence, rename it to
      hci_conn_drop() so we can later fix ref-counting and introduce
      hci_conn_put().
      
      hci_conn_hold() and hci_conn_put() are currently used to manage how long a
      connection should be held alive. When the last user drops the connection,
      we spawn a delayed work that performs the disconnect. Obviously, this has
      nothing to do with ref-counting for the _object_ but rather for the
      keep-alive of the connection.
      
      But we really _need_ proper ref-counting for the _object_ to allow
      connection-users like rfcomm-tty, HIDP or others.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      76a68ba0
  14. 01 2月, 2013 1 次提交
  15. 09 11月, 2012 1 次提交
  16. 12 10月, 2012 1 次提交
  17. 11 10月, 2012 1 次提交
  18. 27 8月, 2012 1 次提交
  19. 15 8月, 2012 1 次提交
    • A
      Bluetooth: Fix use-after-free bug in SMP · 61a0cfb0
      Andre Guedes 提交于
      If SMP fails, we should always cancel security_timer delayed work.
      Otherwise, security_timer function may run after l2cap_conn object
      has been freed.
      
      This patch fixes the following warning reported by ODEBUG:
      
      WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
      Hardware name: Bochs
      ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27
      Modules linked in: btusb bluetooth
      Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4
      Call Trace:
       [<ffffffff81174600>] ? free_obj_work+0x4a/0x7f
       [<ffffffff81023eb8>] warn_slowpath_common+0x7e/0x97
       [<ffffffff81023f65>] warn_slowpath_fmt+0x41/0x43
       [<ffffffff811746b1>] debug_print_object+0x7c/0x8d
       [<ffffffff810394f0>] ? __queue_work+0x241/0x241
       [<ffffffff81174fdd>] debug_check_no_obj_freed+0x92/0x159
       [<ffffffff810ac08e>] slab_free_hook+0x6f/0x77
       [<ffffffffa0019145>] ? l2cap_conn_del+0x148/0x157 [bluetooth]
       [<ffffffff810ae408>] kfree+0x59/0xac
       [<ffffffffa0019145>] l2cap_conn_del+0x148/0x157 [bluetooth]
       [<ffffffffa001b9a2>] l2cap_recv_frame+0xa77/0xfa4 [bluetooth]
       [<ffffffff810592f9>] ? trace_hardirqs_on_caller+0x112/0x1ad
       [<ffffffffa001c86c>] l2cap_recv_acldata+0xe2/0x264 [bluetooth]
       [<ffffffffa0002b2f>] hci_rx_work+0x235/0x33c [bluetooth]
       [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
       [<ffffffff81038e22>] process_one_work+0x185/0x2fe
       [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
       [<ffffffff81059f2e>] ? lock_acquired+0x1b5/0x1cf
       [<ffffffffa00028fa>] ? le_scan_work+0x11d/0x11d [bluetooth]
       [<ffffffff81036fb6>] ? spin_lock_irq+0x9/0xb
       [<ffffffff81039209>] worker_thread+0xcf/0x175
       [<ffffffff8103913a>] ? rescuer_thread+0x175/0x175
       [<ffffffff8103cfe0>] kthread+0x95/0x9d
       [<ffffffff812c5054>] kernel_threadi_helper+0x4/0x10
       [<ffffffff812c36b0>] ? retint_restore_args+0x13/0x13
       [<ffffffff8103cf4b>] ? flush_kthread_worker+0xdb/0xdb
       [<ffffffff812c5050>] ? gs_change+0x13/0x13
      
      This bug can be reproduced using hctool lecc or l2test tools and
      bluetoothd not running.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      61a0cfb0
  20. 07 8月, 2012 1 次提交
  21. 08 6月, 2012 2 次提交
  22. 05 6月, 2012 1 次提交
  23. 09 5月, 2012 1 次提交
  24. 08 3月, 2012 1 次提交