linux-toradex.git/net/bluetooth, branch v4.4.93

Bluetooth: Properly check L2CAP config option output buffer length

2017-09-13T21:09:46+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:19:26+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:19:26+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:19:25+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: use constant time memory comparison for secret values

2017-07-27T22:06:04+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:27:02+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: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

2016-08-20T16:09:19+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: Greg Kroah-Hartman

Bluetooth: Fix potential buffer overflow with Add Advertising

2016-04-12T16:08:54+00:00

commit 6a0e78072c2ae7b20b14e0249d8108441ea928d2 upstream.

The Add Advertising command handler does the appropriate checks for
the AD and Scan Response data, however fails to take into account the
general length of the mgmt command itself, which could lead to
potential buffer overflows. This patch adds the necessary check that
the mgmt command length is consistent with the given ad and scan_rsp
lengths.

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

Bluetooth: 6lowpan: Fix handling of uncompressed IPv6 packets

2016-03-03T23:07:16+00:00

commit 87f5fedb3bebbbb566f847dd0c567fcea49a36a6 upstream.

This patch fixes incorrect handling of the 6lowpan packets that contain
uncompressed IPv6 header.

RFC4944 specifies a special dispatch for 6lowpan to carry uncompressed
IPv6 header. This dispatch (1 byte long) has to be removed during
reception and skb data pointer has to be moved. To correctly point in
the beginning of the IPv6 header the dispatch byte has to be pulled off
before packet can be processed by netif_rx_in().

Test scenario: IPv6 packets are not correctly interpreted by the network
layer when IPv6 header is not compressed (e.g. ICMPv6 Echo Reply is not
propagated correctly to the ICMPv6 layer because the extra byte will make
the header look corrupted).

Similar approach is done for IEEE 802.15.4.

Signed-off-by: Lukasz Duda 
Signed-off-by: Glenn Ruben Bakke 
Acked-by: Jukka Rissanen 
Signed-off-by: Johan Hedberg 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: 6lowpan: Fix kernel NULL pointer dereferences

2016-03-03T23:07:16+00:00

commit 4c58f3282e3de43d34f8955f8eca676294380bf9 upstream.

The fixes provided in this patch assigns a valid net_device structure to
skb before dispatching it for further processing.

Scenario #1:
============

Bluetooth 6lowpan receives an uncompressed IPv6 header, and dispatches it
to netif. The following error occurs:

Null pointer dereference error #1 crash log:

[  845.854013] BUG: unable to handle kernel NULL pointer dereference at
               0000000000000048
[  845.855785] IP: [] enqueue_to_backlog+0x56/0x240
...
[  845.909459] Call Trace:
[  845.911678]  [] netif_rx_internal+0x44/0xf0

The first modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in order to set a valid net_device before
processing the skb by netif_rx_ni().

Scenario #2:
============

Bluetooth 6lowpan receives an UDP compressed message which needs further
decompression by nhc_udp. The following error occurs:

Null pointer dereference error #2 crash log:

[   63.295149] BUG: unable to handle kernel NULL pointer dereference at
               0000000000000840
[   63.295931] IP: [] udp_uncompress+0x320/0x626
               [nhc_udp]

The second modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in the case of a udp compressed packet.
The 6lowpan udp_uncompress function expects that the net_device is set in
the skb when checking lltype.

Signed-off-by: Glenn Ruben Bakke 
Signed-off-by: Lukasz Duda 
Acked-by: Jukka Rissanen 
Signed-off-by: Johan Hedberg 
Signed-off-by: Greg Kroah-Hartman