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

Bluetooth: Properly check L2CAP config option output buffer length

2017-09-13T21:03:47+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: Greg Kroah-Hartman

Bluetooth: bnep: fix possible might sleep error in bnep_session

2017-08-30T08:16:57+00:00

commit 25717382c1dd0ddced2059053e3ca5088665f7a5 upstream.

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 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: cmtp: fix possible might sleep error in cmtp_session

2017-08-30T08:16:57+00:00

commit f06d977309d09253c744e54e75c5295ecc52b7b4 upstream.

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 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hidp: fix possible might sleep error in hidp_session_thread

2017-08-30T08:16:57+00:00

commit 5da8e47d849d3d37b14129f038782a095b9ad049 upstream.

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 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

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

2017-08-11T16:30:09+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: Greg Kroah-Hartman

Bluetooth: Fix potential NULL dereference

2017-08-11T16:30:09+00:00

commit 88d9077c27d0c1a7c022d9dc987640beecf23560 upstream.

The bnep_get_device function may be triggered by an ioctl just after a
connection has gone down. In such a case the respective L2CAP chan->conn
pointer will get set to NULL (by l2cap_chan_del). This patch adds a
missing NULL check for this case in the bnep_get_device() function.

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

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

2017-08-11T16:30:09+00:00

commit 71bb99a02b32b4cc4265118e85f6035ca72923f0 upstream.

same story as cmtp

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: use constant time memory comparison for secret values

2017-07-27T22:03:25+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 
Signed-off-by: Greg Kroah-Hartman

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

2017-05-20T12:18:43+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: Greg Kroah-Hartman

Bluetooth: make hci_test_bit's addr const

2017-02-08T08:43:03+00:00

commit 9391976a4da0d2a30abdb8d2704cfc7bf4bf9aab upstream.

gcc5 warns about passing a const array to hci_test_bit which takes a
non-const pointer:
net/bluetooth/hci_sock.c: In function ‘hci_sock_sendmsg’:
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of ‘hci_test_bit’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]
        &hci_sec_filter.ocf_mask[ogf])) &&
        ^
net/bluetooth/hci_sock.c:49:19: note: expected ‘void *’ but argument is of type ‘const __u32 (*)[4] {aka const unsigned int (*)[4]}’
 static inline int hci_test_bit(int nr, void *addr)
                   ^

So make 'addr' 'const void *'.

Signed-off-by: Jiri Slaby 
Signed-off-by: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: Greg Kroah-Hartman