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

Bluetooth: Properly check L2CAP config option output buffer length

2017-10-04T01:36:47+00:00

[ Upstream commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 ]

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

Cc: stable@vger.kernel.org
Signed-off-by: Ben Seri 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

Bluetooth: bnep: fix possible might sleep error in bnep_session

2017-10-04T01:36:35+00:00

[ Upstream commit 25717382c1dd0ddced2059053e3ca5088665f7a5 ]

It looks like bnep_session has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen 
Reviewed-by: Brian Norris 
Reviewed-by: AL Yu-Chen Cho 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: cmtp: fix possible might sleep error in cmtp_session

2017-10-04T01:36:35+00:00

[ Upstream commit f06d977309d09253c744e54e75c5295ecc52b7b4 ]

It looks like cmtp_session has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen 
Reviewed-by: Brian Norris 
Reviewed-by: AL Yu-Chen Cho 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hidp: fix possible might sleep error in hidp_session_thread

2017-10-04T01:36:35+00:00

[ Upstream commit 5da8e47d849d3d37b14129f038782a095b9ad049 ]

It looks like hidp_session_thread has same pattern as the issue reported in
old rfcomm:

	while (1) {
		set_current_state(TASK_INTERRUPTIBLE);
		if (condition)
			break;
		// may call might_sleep here
		schedule();
	}
	__set_current_state(TASK_RUNNING);

Which fixed at:
	dfb2fae Bluetooth: Fix nested sleeps

So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/

Signed-off-by: Jeffy Chen 
Tested-by: AL Yu-Chen Cho 
Tested-by: Rohit Vaswani 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: use constant time memory comparison for secret values

2017-09-01T18:24:28+00:00

[ Upstream commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

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