1. 02 10月, 2014 3 次提交
    • J
      Bluetooth: 6lowpan: Avoid memory leak if memory allocation fails · a7807d73
      Jukka Rissanen 提交于
      If skb_unshare() returns NULL, then we leak the original skb.
      Solution is to use temp variable to hold the new skb.
      Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      a7807d73
    • J
      Bluetooth: 6lowpan: Memory leak as the skb is not freed · fc12518a
      Jukka Rissanen 提交于
      The earlier multicast commit 36b3dd25 ("Bluetooth: 6lowpan:
      Ensure header compression does not corrupt IPv6 header") lost one
      skb free which then caused memory leak.
      Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      fc12518a
    • J
      Bluetooth: Fix lockdep warning with l2cap_chan_connect · 02e246ae
      Johan Hedberg 提交于
      The L2CAP connection's channel list lock (conn->chan_lock) must never be
      taken while already holding a channel lock (chan->lock) in order to
      avoid lock-inversion and lockdep warnings. So far the l2cap_chan_connect
      function has acquired the chan->lock early in the function and then
      later called l2cap_chan_add(conn, chan) which will try to take the
      conn->chan_lock. This violates the correct order of taking the locks and
      may lead to the following type of lockdep warnings:
      
      -> #1 (&conn->chan_lock){+.+...}:
             [<c109324d>] lock_acquire+0x9d/0x140
             [<c188459c>] mutex_lock_nested+0x6c/0x420
             [<d0aab48e>] l2cap_chan_add+0x1e/0x40 [bluetooth]
             [<d0aac618>] l2cap_chan_connect+0x348/0x8f0 [bluetooth]
             [<d0cc9a91>] lowpan_control_write+0x221/0x2d0 [bluetooth_6lowpan]
      -> #0 (&chan->lock){+.+.+.}:
             [<c10928d8>] __lock_acquire+0x1a18/0x1d20
             [<c109324d>] lock_acquire+0x9d/0x140
             [<c188459c>] mutex_lock_nested+0x6c/0x420
             [<d0ab05fd>] l2cap_connect_cfm+0x1dd/0x3f0 [bluetooth]
             [<d0a909c4>] hci_le_meta_evt+0x11a4/0x1260 [bluetooth]
             [<d0a910eb>] hci_event_packet+0x3ab/0x3120 [bluetooth]
             [<d0a7cb08>] hci_rx_work+0x208/0x4a0 [bluetooth]
      
             CPU0                    CPU1
             ----                    ----
        lock(&conn->chan_lock);
                                     lock(&chan->lock);
                                     lock(&conn->chan_lock);
        lock(&chan->lock);
      
      Before calling l2cap_chan_add() the channel is not part of the
      conn->chan_l list, and can therefore only be accessed by the L2CAP user
      (such as l2cap_sock.c). We can therefore assume that it is the
      responsibility of the user to handle mutual exclusion until this point
      (which we can see is already true in l2cap_sock.c by it in many places
      touching chan members without holding chan->lock).
      
      Since the hci_conn and by exctension l2cap_conn creation in the
      l2cap_chan_connect() function depend on chan details we cannot simply
      add a mutex_lock(&conn->chan_lock) in the beginning of the function
      (since the conn object doesn't yet exist there). What we can do however
      is move the chan->lock taking later into the function where we already
      have the conn object and can that way take conn->chan_lock first.
      
      This patch implements the above strategy and does some other necessary
      changes such as using __l2cap_chan_add() which assumes conn->chan_lock
      is held, as well as adding a second needed label so the unlocking
      happens as it should.
      Reported-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      02e246ae
  2. 30 9月, 2014 3 次提交
  3. 29 9月, 2014 3 次提交
  4. 25 9月, 2014 2 次提交
  5. 24 9月, 2014 6 次提交
  6. 23 9月, 2014 1 次提交
  7. 18 9月, 2014 1 次提交
    • J
      Bluetooth: Fix setting correct security level when initiating SMP · 5eb596f5
      Johan Hedberg 提交于
      We can only determine the final security level when both pairing request
      and response have been exchanged. When initiating pairing the starting
      target security level is set to MEDIUM unless explicitly specified to be
      HIGH, so that we can still perform pairing even if the remote doesn't
      have MITM capabilities. However, once we've received the pairing
      response we should re-consult the remote and local IO capabilities and
      upgrade the target security level if necessary.
      
      Without this patch the resulting Long Term Key will occasionally be
      reported to be unauthenticated when it in reality is an authenticated
      one.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      5eb596f5
  8. 17 9月, 2014 2 次提交
  9. 16 9月, 2014 2 次提交
  10. 15 9月, 2014 4 次提交
  11. 14 9月, 2014 1 次提交
  12. 13 9月, 2014 1 次提交
  13. 11 9月, 2014 8 次提交
  14. 10 9月, 2014 1 次提交
  15. 09 9月, 2014 2 次提交