linux.git/net/bluetooth, branch v2.6.38

Bluetooth: Release BTM while sleeping to avoid deadlock

2011-02-16T18:54:11+00:00

Signed-off-by: Vladislav P 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Set conn state to BT_DISCONN to avoid multiple responses

2011-02-02T14:47:59+00:00

This patch fixes a minor issue that two connection responses will be sent
for one L2CAP connection request. If the L2CAP connection request is first
blocked due to security reason and responded with reason "security block",
the state of the connection remains BT_CONNECT2. If a pairing procedure
completes successfully before the ACL connection is down, local host will
send another connection complete response. See the following packets
captured by hcidump.

2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
    0000: 0c 00 01 00 03 19 08 00  41 00 53 00 03 00 00 00  ........A.S.....
... ...

2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 12
... ...

2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
      Connection successful

Signed-off-by: Liang Bao 
Acked-by: Ville Tervo 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix race condition with conn->sec_level

2011-01-19T16:43:11+00:00

The conn->sec_level value is supposed to represent the current level of
security that the connection has. However, by assigning to it before
requesting authentication it will have the wrong value during the
authentication procedure. To fix this a pending_sec_level variable is
added which is used to track the desired security level while making
sure that sec_level always represents the current level of security.

Signed-off-by: Johan Hedberg 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix authentication request for L2CAP raw sockets

2011-01-19T16:40:43+00:00

When there is an existing connection l2cap_check_security needs to be
called to ensure that the security level of the new socket is fulfilled.
Normally l2cap_do_start takes care of this, but that function doesn't
get called for SOCK_RAW type sockets. This patch adds the necessary
l2cap_check_security call to the appropriate branch in l2cap_do_connect.

Signed-off-by: Johan Hedberg 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Create a unified auth_type evaluation function

2011-01-19T16:40:43+00:00

The logic for determining the needed auth_type for an L2CAP socket is
rather complicated and has so far been duplicated in
l2cap_check_security as well as l2cap_do_connect. Additionally the
l2cap_check_security code was completely missing the handling of
SOCK_RAW type sockets. This patch creates a unified function for the
evaluation and makes l2cap_do_connect and l2cap_check_security use that
function.

Signed-off-by: Johan Hedberg 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix MITM protection requirement preservation

2011-01-19T16:40:43+00:00

If an existing connection has a MITM protection requirement (the first
bit of the auth_type) then that requirement should not be cleared by new
sockets that reuse the ACL but don't have that requirement.

Signed-off-by: Johan Hedberg 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Revert "Bluetooth: Update sec_level/auth_type for already existing connections"

2011-01-19T16:40:42+00:00

This reverts commit 045309820afe047920a50de25634dab46a1e851d. That
commit is wrong for two reasons:

- The conn->sec_level shouldn't be updated without performing
authentication first (as it's supposed to represent the level of
security that the existing connection has)

- A higher auth_type value doesn't mean "more secure" like the commit
seems to assume. E.g. dedicated bonding with MITM protection is 0x03
whereas general bonding without MITM protection is 0x04. hci_conn_auth
already takes care of updating conn->auth_type so hci_connect doesn't
need to do it.

Signed-off-by: Johan Hedberg 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Never deallocate a session when some DLC points to it

2011-01-19T16:40:42+00:00

Fix a bug introduced in commit 9cf5b0ea3a7f1432c61029f7aaf4b8b338628884:
function rfcomm_recv_ua calls rfcomm_session_put without checking that
the session is not referenced by some DLC. If the session is freed, that
DLC would refer to deallocated memory, causing an oops later, as shown
in this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=15994

Signed-off-by: Lukas Turek <8an@praha12.net>
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix leaking blacklist when unregistering a hci device

2011-01-19T16:40:42+00:00

The blacklist should be freed before the hci device gets unregistered.

Signed-off-by: Johan Hedberg 
Signed-off-by: Gustavo F. Padovan

Bluetooth: l2cap: fix misuse of logical operation in place of bitop

2011-01-19T16:40:42+00:00

CC: Marcel Holtmann 
CC: "Gustavo F. Padovan" 
CC: João Paulo Rechi Vita 
Signed-off-by: David Sterba 
Signed-off-by: Gustavo F. Padovan