linux-stable.git/net/bluetooth, branch v3.15.4

Bluetooth: Fix properly ignoring LTKs of unknown types

2014-07-01T03:14:03+00:00

commit 61b433579b6ffecb1d3534fd482dcd48535277c8 upstream.

In case there are new LTK types in the future we shouldn't just blindly
assume that != MGMT_LTK_UNAUTHENTICATED means that the key is
authenticated. This patch adds explicit checks for each allowed key type
in the form of a switch statement and skips any key which has an unknown
value.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Clearly distinguish mgmt LTK type from authenticated property

2014-07-01T03:14:03+00:00

commit d7b2545023ecfde94d3ea9c03c5480ac18da96c9 upstream.

On the mgmt level we have a key type parameter which currently accepts
two possible values: 0x00 for unauthenticated and 0x01 for
authenticated. However, in the internal struct smp_ltk representation we
have an explicit "authenticated" boolean value.

To make this distinction clear, add defines for the possible mgmt values
and do conversion to and from the internal authenticated value.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix missing check for FIPS security level

2014-07-01T03:13:59+00:00

commit f3fb0b58c85666f73139963a7a04d7878f3d22c9 upstream.

When checking whether a legacy link key provides at least HIGH security
level we also need to check for FIPS level which is one step above HIGH.
This patch fixes a missing check in the hci_link_key_request_evt()
function.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix requiring SMP MITM for outgoing connections

2014-07-01T03:13:59+00:00

commit 79897d2097a629179e142014ecd3cdce6eac7f0e upstream.

Due to recent changes to the way that the MITM requirement is set for
outgoing pairing attempts we can no longer rely on the hcon->auth_type
variable (which is actually good since it was formed from BR/EDR
concepts that don't really exist for SMP).

To match the logic that BR/EDR now uses simply rely on the local IO
capability and/or needed security level to set the MITM requirement for
outgoing pairing requests.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix authentication check for FIPS security level

2014-07-01T03:13:59+00:00

commit 7e3691e13ab51f3491e996e2edaf99b173621288 upstream.

When checking whether we need to request authentication or not we should
include HCI_SECURITY_FIPS to the levels that always need authentication.
This patch fixes check for it in the hci_outgoing_auth_needed()
function.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix L2CAP deadlock

2014-07-01T03:13:59+00:00

commit 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 upstream.

-[0x01 Introduction

We have found a programming error causing a deadlock in Bluetooth subsystem
of Linux kernel. The problem is caused by missing release_sock() call when
L2CAP connection creation fails due full accept queue.

The issue can be reproduced with 3.15-rc5 kernel and is also present in
earlier kernels.

-[0x02 Details

The problem occurs when multiple L2CAP connections are created to a PSM which
contains listening socket (like SDP) and left pending, for example,
configuration (the underlying ACL link is not disconnected between
connections).

When L2CAP connection request is received and listening socket is found the
l2cap_sock_new_connection_cb() function (net/bluetooth/l2cap_sock.c) is called.
This function locks the 'parent' socket and then checks if the accept queue
is full.

1178         lock_sock(parent);
1179
1180         /* Check for backlog size */
1181         if (sk_acceptq_is_full(parent)) {
1182                 BT_DBG("backlog full %d", parent->sk_ack_backlog);
1183                 return NULL;
1184         }

If case the accept queue is full NULL is returned, but the 'parent' socket
is not released. Thus when next L2CAP connection request is received the code
blocks on lock_sock() since the parent is still locked.

Also note that for connections already established and waiting for
configuration to complete a timeout will occur and l2cap_chan_timeout()
(net/bluetooth/l2cap_core.c) will be called. All threads calling this
function will also be blocked waiting for the channel mutex since the thread
which is waiting on lock_sock() alread holds the channel mutex.

We were able to reproduce this by sending continuously L2CAP connection
request followed by disconnection request containing invalid CID. This left
the created connections pending configuration.

After the deadlock occurs it is impossible to kill bluetoothd, btmon will not
get any more data etc. requiring reboot to recover.

-[0x03 Fix

Releasing the 'parent' socket when l2cap_sock_new_connection_cb() returns NULL
seems to fix the issue.

Signed-off-by: Jukka Taimisto 
Reported-by: Tommi Mäkilä 
Signed-off-by: Johan Hedberg 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: 6LoWPAN: Fix MAC address universal/local bit handling

2014-07-01T03:13:59+00:00

commit 62bbd5b35994eaf30519f126765d7f6af9cd3526 upstream.

The universal/local bit handling was incorrectly done in the code.

So when setting EUI address from BD address we do this:
- If BD address type is PUBLIC, then we clear the universal bit
  in EUI address. If the address type is RANDOM, then the universal
  bit is set (BT 6lowpan draft chapter 3.2.2)
- After this we invert the universal/local bit according to RFC 2464

When figuring out BD address we do the reverse:
- Take EUI address from stateless IPv6 address, invert the
  universal/local bit according to RFC 2464
- If universal bit is 1 in this modified EUI address, then address
  type is set to RANDOM, otherwise it is PUBLIC

Note that 6lowpan_iphc.[ch] does the final toggling of U/L bit
before sending or receiving the network packet.

Signed-off-by: Jukka Rissanen 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix L2CAP LE debugfs entries permissions

2014-05-14T16:07:07+00:00

0466 was probably meant to be 0644, there's no reason why everyone
except root could write there.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org

Bluetooth: Fix redundant encryption request for reauthentication

2014-04-25T06:47:15+00:00

When we're performing reauthentication (in order to elevate the
security level from an unauthenticated key to an authenticated one) we
do not need to issue any encryption command once authentication
completes. Since the trigger for the encryption HCI command is the
ENCRYPT_PEND flag this flag should not be set in this scenario.
Instead, the REAUTH_PEND flag takes care of all necessary steps for
reauthentication.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org

Bluetooth: Fix triggering BR/EDR L2CAP Connect too early

2014-04-25T06:47:15+00:00

Commit 1c2e004183178 introduced an event handler for the encryption key
refresh complete event with the intent of fixing some LE/SMP cases.
However, this event is shared with BR/EDR and there we actually want to
act only on the auth_complete event (which comes after the key refresh).

If we do not do this we may trigger an L2CAP Connect Request too early
and cause the remote side to return a security block error.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org