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

Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with l2cap socket

2018-01-01T20:52:08+00:00

commit 71bb99a02b32b4cc4265118e85f6035ca72923f0 upstream.

same story as cmtp

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with l2cap socket

2018-01-01T20:52:08+00:00

commit 96c26653ce65bf84f3212f8b00d4316c1efcbf4c upstream.

... rather than relying on ciptool(8) never passing it anything else.  Give
it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops,
trying to evaluate &l2cap_pi(sock->sk)->chan->dst...

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: Properly check L2CAP config option output buffer length

2017-10-12T14:28:11+00:00

commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 upstream.

Validate the output buffer length for L2CAP config requests and responses
to avoid overflowing the stack buffer used for building the option blocks.

Signed-off-by: Ben Seri 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

Bluetooth: use constant time memory comparison for secret values

2017-10-12T14:27:47+00:00

commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream.

This file is filled with complex cryptography. Thus, the comparisons of
MACs and secret keys and curve points and so forth should not add timing
attacks, which could either result in a direct forgery, or, given the
complexity, some other type of attack.

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Marcel Holtmann 
[bwh: Backported to 3.16:
 - Drop inapplicable changes
 - Adjust context]
Signed-off-by: Ben Hutchings

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

2017-08-26T01:14:42+00:00

commit ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 upstream.

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 
Signed-off-by: Ben Hutchings

Bluetooth: Fix potential NULL dereference in RFCOMM bind callback

2016-11-20T01:17:37+00:00

commit 951b6a0717db97ce420547222647bcc40bf1eacd upstream.

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

Signed-off-by: Jaganath Kanakkassery 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

2016-11-20T01:16:52+00:00

commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.

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 
Signed-off-by: Ben Hutchings

bluetooth: Validate socket address length in sco_sock_bind().

2016-01-04T17:20:47+00:00

commit 5233252fce714053f0151680933571a2da9cbfb4 upstream.

Signed-off-by: David S. Miller 
Signed-off-by: Luis Henriques

Bluetooth: hidp: fix device disconnect on idle timeout

2015-12-13T17:48:51+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: Luis Henriques

Bluetooth: Fix LE connection timeout deadlock

2015-01-05T13:33:42+00:00

commit 980ffc0a2cec2c37589cc97993e1ad17252f4f47 upstream.

The le_conn_timeout() may call hci_le_conn_failed() which in turn may
call hci_conn_del(). Trying to use the _sync variant for cancelling the
conn timeout from hci_conn_del() could therefore result in a deadlock.
This patch converts hci_conn_del() to use the non-sync variant so the
deadlock is not possible.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Luis Henriques