linux-stable.git/net/bluetooth, branch v4.1.41

Bluetooth: Fix user channel for 32bit userspace on 64bit kernel

2017-05-17T19:08:24+00:00

[ Upstream commit ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 ]

Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
defined as 0x80000000. This results in sendmsg failure if used from 32bit
userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
in flags check in hci_sock_sendmsg.

Signed-off-by: Szymon Janc 
Signed-off-by: Marko Kiiskila 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

Bluetooth: Fix potential NULL dereference in RFCOMM bind callback

2016-12-23T13:56:36+00:00

[ Upstream commit 951b6a0717db97ce420547222647bcc40bf1eacd ]

addr can be NULL and it should not be dereferenced before NULL checking.

References: CVE-2015-8956
Signed-off-by: Jaganath Kanakkassery 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin

Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

2016-08-20T03:07:58+00:00

[ Upstream commit 23bc6ab0a0912146fd674a0becc758c3162baabc ]

When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.

Signed-off-by: Amadeusz Sławiński 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

bluetooth: Validate socket address length in sco_sock_bind().

2016-01-23T04:54:15+00:00

[ Upstream commit 5233252fce714053f0151680933571a2da9cbfb4 ]

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix removing connection parameters when unpairing

2015-12-09T19:03:21+00:00

commit a6ad2a6b9cc1d9d791aee5462cfb8528f366f1d4 upstream.

The commit 89cbb0638e9b7 introduced support for deferred connection
parameter removal when unpairing by removing them only once an
existing connection gets disconnected. However, it failed to address
the scenario when we're *not* connected and do an unpair operation.

What makes things worse is that most user space BlueZ versions will
first issue a disconnect request and only then unpair, meaning the
buggy code will be triggered every time. This effectively causes the
kernel to resume scanning and reconnect to a device for which we've
removed all keys and GATT database information.

This patch fixes the issue by adding the missing call to the
hci_conn_params_del() function to a branch which handles the case of
no existing connection.

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

Bluetooth: hidp: fix device disconnect on idle timeout

2015-12-09T19:03:21+00:00

commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.

The HIDP specs define an idle-timeout which automatically disconnects a
device. This has always been implemented in the HIDP layer and forced a
synchronous shutdown of the hidp-scheduler. This works just fine, but
lacks a forced disconnect on the underlying l2cap channels. This has been
broken since:

    commit 5205185d461d5902325e457ca80bd421127b7308
    Author: David Herrmann 
    Date:   Sat Apr 6 20:28:47 2013 +0200

        Bluetooth: hidp: remove old session-management

The old session-management always forced an l2cap error on the ctrl/intr
channels when shutting down. The new session-management skips this, as we
don't want to enforce channel policy on the caller. In other words, if
user-space removes an HIDP device, the underlying channels (which are
*owned* and *referenced* by user-space) are still left active. User-space
needs to call shutdown(2) or close(2) to release them.

Unfortunately, this does not work with idle-timeouts. There is no way to
signal user-space that the HIDP layer has been stopped. The API simply
does not support any event-passing except for poll(2). Hence, we restore
old behavior and force EUNATCH on the sockets if the HIDP layer is
disconnected due to idle-timeouts (behavior of explicit disconnects
remains unmodified). User-space can still call

    getsockopt(..., SO_ERROR, ...)

..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
still be re-used (which nobody does so far, though). Therefore, the API
still supports the new behavior, but with this patch it's also compatible
to the old implicit channel shutdown.

Reported-by: Mark Haun 
Reported-by: Luiz Augusto von Dentz 
Signed-off-by: David Herrmann 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Delay check for conn->smp in smp_conn_security()

2015-10-22T21:43:18+00:00

commit d8949aad3eab5d396f4fefcd581773bf07b9a79e upstream.

There are several actions that smp_conn_security() might make that do
not require a valid SMP context (conn->smp pointer). One of these
actions is to encrypt the link with an existing LTK. If the SMP
context wasn't initialized properly we should still allow the
independent actions to be done, i.e. the check for the context should
only be done at the last possible moment.

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

Bluetooth: Fix NULL pointer dereference in smp_conn_security

2015-08-17T03:52:11+00:00

commit 25ba265390c09b0a2b2f3fd9ba82e37248b7a371 upstream.

The l2cap_conn->smp pointer may be NULL for various valid reasons where SMP has
failed to initialize properly. One such scenario is when crypto support is
missing, another when the adapter has been powered on through a legacy method.
The smp_conn_security() function should have the appropriate check for this
situation to avoid NULL pointer dereferences.

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

Bluetooth: Fix race condition with user channel and setup stage

2015-08-03T16:28:58+00:00

commit 781f899f2f9d8b71e35225a087f90052059486c5 upstream.

During the initial setup stage of a controller, the low-level transport
is actually active. This means that HCI_UP is true. To avoid toggling
the transport off and back on again for normal operation the kernel
holds a grace period with HCI_AUTO_OFF that will turn the low-level
transport off in case no user is present.

The idea of the grace period is important to avoid having to initialize
all of the controller twice. So legacy ioctl and the new management
interface knows how to clear this grace period and then start normal
operation.

For the user channel operation this grace period has not been taken into
account which results in the problem that HCI_UP and HCI_AUTO_OFF are
set and the kernel will return EBUSY. However from a system point of
view the controller is ready to be grabbed by either the ioctl, the
management interface or the user channel.

This patch brings the user channel to the same level as the other two
entries for operating a controller.

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

Bluetooth: Fix remote name event return directly.

2015-05-14T08:35:04+00:00

This patch fixes hci_remote_name_evt dose not resolve name during
discovery status is RESOLVING. Before simultaneous dual mode scan enabled,
hci_check_pending_name will set discovery status to STOPPED eventually.

Signed-off-by: Wesley Kuo 
Signed-off-by: Marcel Holtmann