1. 22 9月, 2012 1 次提交
  2. 27 8月, 2012 2 次提交
  3. 16 8月, 2012 6 次提交
  4. 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
  5. 07 8月, 2012 7 次提交
    • J
      Bluetooth: Fix socket not getting freed if l2cap channel create fails · 49dfbb91
      Jaganath Kanakkassery 提交于
      If l2cap_chan_create() fails then it will return from l2cap_sock_kill
      since zapped flag of sk is reset.
      Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      49dfbb91
    • A
      Bluetooth: smp: Fix possible NULL dereference · d08fd0e7
      Andrei Emeltchenko 提交于
      smp_chan_create might return NULL so we need to check before
      dereferencing smp.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      d08fd0e7
    • R
      Bluetooth: Set name_state to unknown when entry name is empty · c3e7c0d9
      Ram Malovany 提交于
      When the name of the given entry is empty , the state needs to be
      updated accordingly.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRam Malovany <ramm@ti.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      c3e7c0d9
    • R
      Bluetooth: Fix using a NULL inquiry cache entry · 7cc8380e
      Ram Malovany 提交于
      If the device was not found in a list of found devices names of which
      are pending.This may happen in a case when HCI Remote Name Request
      was sent as a part of incoming connection establishment procedure.
      Hence there is no need to continue resolving a next name as it will
      be done upon receiving another Remote Name Request Complete Event.
      This will fix a kernel crash when trying to use this entry to resolve
      the next name.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRam Malovany <ramm@ti.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      7cc8380e
    • R
      Bluetooth: Fix using NULL inquiry entry · c810089c
      Ram Malovany 提交于
      If entry wasn't found in the hci_inquiry_cache_lookup_resolve do not
      resolve the name.This will fix a kernel crash when trying to use NULL
      pointer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NRam Malovany <ramm@ti.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      c810089c
    • S
      Bluetooth: Fix legacy pairing with some devices · a9ea3ed9
      Szymon Janc 提交于
      Some devices e.g. some Android based phones don't do SDP search before
      pairing and cancel legacy pairing when ACL is disconnected.
      
      PIN Code Request event which changes ACL timeout to HCI_PAIRING_TIMEOUT
      is only received after remote user entered PIN.
      
      In that case no L2CAP is connected so default HCI_DISCONN_TIMEOUT
      (2 seconds) is being used to timeout ACL connection. This results in
      problems with legacy pairing as remote user has only few seconds to
      enter PIN before ACL is disconnected.
      
      Increase disconnect timeout for incomming connection to
      HCI_PAIRING_TIMEOUT if SSP is disabled and no linkey exists.
      
      To avoid keeping ACL alive for too long after SDP search set ACL
      timeout back to HCI_DISCONN_TIMEOUT when L2CAP is connected.
      
      2012-07-19 13:24:43.413521 < HCI Command: Create Connection (0x01|0x0005) plen 13
          bdaddr 00:02:72:D6:6A:3F ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
          Packet type: DM1 DM3 DM5 DH1 DH3 DH5
      2012-07-19 13:24:43.425224 > HCI Event: Command Status (0x0f) plen 4
          Create Connection (0x01|0x0005) status 0x00 ncmd 1
      2012-07-19 13:24:43.885222 > HCI Event: Role Change (0x12) plen 8
          status 0x00 bdaddr 00:02:72:D6:6A:3F role 0x01
          Role: Slave
      2012-07-19 13:24:44.054221 > HCI Event: Connect Complete (0x03) plen 11
          status 0x00 handle 42 bdaddr 00:02:72:D6:6A:3F type ACL encrypt 0x00
      2012-07-19 13:24:44.054313 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
          handle 42
      2012-07-19 13:24:44.055176 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
          bdaddr 00:02:72:D6:6A:3F mode 0
      2012-07-19 13:24:44.056217 > HCI Event: Max Slots Change (0x1b) plen 3
          handle 42 slots 5
      2012-07-19 13:24:44.059218 > HCI Event: Command Status (0x0f) plen 4
          Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
      2012-07-19 13:24:44.062192 > HCI Event: Command Status (0x0f) plen 4
          Unknown (0x00|0x0000) status 0x00 ncmd 1
      2012-07-19 13:24:44.067219 > HCI Event: Read Remote Supported Features (0x0b) plen 11
          status 0x00 handle 42
          Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
      2012-07-19 13:24:44.067248 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
          handle 42 page 1
      2012-07-19 13:24:44.071217 > HCI Event: Command Status (0x0f) plen 4
          Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
      2012-07-19 13:24:44.076218 > HCI Event: Read Remote Extended Features (0x23) plen 13
          status 0x00 handle 42 page 1 max 1
          Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
      2012-07-19 13:24:44.076249 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
          bdaddr 00:02:72:D6:6A:3F mode 2 clkoffset 0x0000
      2012-07-19 13:24:44.081218 > HCI Event: Command Status (0x0f) plen 4
          Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
      2012-07-19 13:24:44.105214 > HCI Event: Remote Name Req Complete (0x07) plen 255
          status 0x00 bdaddr 00:02:72:D6:6A:3F name 'uw000951-0'
      2012-07-19 13:24:44.105284 < HCI Command: Authentication Requested (0x01|0x0011) plen 2
          handle 42
      2012-07-19 13:24:44.111207 > HCI Event: Command Status (0x0f) plen 4
          Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
      2012-07-19 13:24:44.112220 > HCI Event: Link Key Request (0x17) plen 6
          bdaddr 00:02:72:D6:6A:3F
      2012-07-19 13:24:44.112249 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
          bdaddr 00:02:72:D6:6A:3F
      2012-07-19 13:24:44.115215 > HCI Event: Command Complete (0x0e) plen 10
          Link Key Request Negative Reply (0x01|0x000c) ncmd 1
          status 0x00 bdaddr 00:02:72:D6:6A:3F
      2012-07-19 13:24:44.116215 > HCI Event: PIN Code Request (0x16) plen 6
          bdaddr 00:02:72:D6:6A:3F
      2012-07-19 13:24:48.099184 > HCI Event: Auth Complete (0x06) plen 3
          status 0x13 handle 42
          Error: Remote User Terminated Connection
      2012-07-19 13:24:48.179182 > HCI Event: Disconn Complete (0x05) plen 4
          status 0x00 handle 42 reason 0x13
          Reason: Remote User Terminated Connection
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSzymon Janc <szymon.janc@tieto.com>
      Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      a9ea3ed9
    • G
      Bluetooth: Fix possible deadlock in SCO code · 269c4845
      Gustavo Padovan 提交于
      sco_chan_del() only has conn != NULL when called from sco_conn_del() so
      just move the code from it that deal with conn to sco_conn_del().
      
      [  120.765529]
      [  120.765529] ======================================================
      [  120.766529] [ INFO: possible circular locking dependency detected ]
      [  120.766529] 3.5.0-rc1-10292-g3701f944-dirty #70 Tainted: G        W
      [  120.766529] -------------------------------------------------------
      [  120.766529] kworker/u:3/1497 is trying to acquire lock:
      [  120.766529]  (&(&conn->lock)->rlock#2){+.+...}, at:
      [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth]
      [  120.766529]
      [  120.766529] but task is already holding lock:
      [  120.766529]  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at:
      [<ffffffffa00b8401>] sco_conn_del+0x61/0xe0 [bluetooth]
      [  120.766529]
      [  120.766529] which lock already depends on the new lock.
      [  120.766529]
      [  120.766529]
      [  120.766529] the existing dependency chain (in reverse order) is:
      [  120.766529]
      [  120.766529] -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b85e9>] sco_connect_cfm+0x79/0x300
      [bluetooth]
      [  120.766529]        [<ffffffffa0094b13>]
      hci_sync_conn_complete_evt.isra.90+0x343/0x400 [bluetooth]
      [  120.766529]        [<ffffffffa009d447>] hci_event_packet+0x317/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] -> #0 (&(&conn->lock)->rlock#2){+.+...}:
      [  120.766529]        [<ffffffff81078a8a>] __lock_acquire+0x154a/0x1d30
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170
      [bluetooth]
      [  120.766529]        [<ffffffffa00b8414>] sco_conn_del+0x74/0xe0
      [bluetooth]
      [  120.766529]        [<ffffffffa00b88a2>] sco_disconn_cfm+0x32/0x60
      [bluetooth]
      [  120.766529]        [<ffffffffa0093a82>]
      hci_disconn_complete_evt.isra.53+0x242/0x390 [bluetooth]
      [  120.766529]        [<ffffffffa009d747>] hci_event_packet+0x617/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] other info that might help us debug this:
      [  120.766529]
      [  120.766529]  Possible unsafe locking scenario:
      [  120.766529]
      [  120.766529]        CPU0                    CPU1
      [  120.766529]        ----                    ----
      [  120.766529]   lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]
      lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]   lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      [  120.766529]  *** DEADLOCK ***
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      269c4845
  6. 16 7月, 2012 1 次提交
    • J
      Bluetooth: Change page scan interval in fast connectable mode · 83ce9a06
      Johan Hedberg 提交于
      This patch is based on a user space (hciops) patch which never made it
      upstream but does make sense to include in the mgmt part of the kernel.
      
      (User space) commit message from Dmitriy Paliy:
      "
      Page scan interval in fast connectable mode is changed from 22.5 msec to
      160 msec to perform less aggressive page scanning. This is done
      accordingly to controller vendor recommendation.
      
      Primary concern is that current parameters 22.5 interval, 11.25 window,
      and interleaved scanning occupy whole radio bandwidth. Changing interval
      to 160 msec should be sufficient for both speeding up connection
      establishment and leaving space for other activities, like inquiry scan,
      e.g.
      "
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      83ce9a06
  7. 15 7月, 2012 1 次提交
    • M
      Bluetooth: Use tx window from config response for ack timing · c20f8e35
      Mat Martineau 提交于
      This change addresses an L2CAP ERTM throughput problem when a remote
      device does not fully utilize the available transmit window.
      
      The L2CAP ERTM transmit window size determines the maximum number of
      unacked frames that may be outstanding at any time. It is configured
      separately for each direction of an ERTM connection. Each side sends a
      configuration request with a tx_win field indicating how many unacked
      frames it is capable of receiving before sending an ack. The
      configuration response's tx_win field shows how many frames the
      transmitter will actually send before waiting for an ack.
      
      It's important to trace both the actual transmit window (to check for
      validity of incoming frames) and the number of frames that the
      transmitter will send before waiting (to send acks at the appropriate
      time). Now there are separate tx_win and ack_win values. ack_win is
      updated based on configuration responses, and is used to determine
      when acks are sent.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      c20f8e35
  8. 11 7月, 2012 7 次提交
  9. 30 6月, 2012 3 次提交
  10. 25 6月, 2012 1 次提交
  11. 19 6月, 2012 5 次提交
  12. 14 6月, 2012 1 次提交
  13. 13 6月, 2012 2 次提交
  14. 12 6月, 2012 2 次提交