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

Bluetooth: hidp: buffer overflow in hidp_process_report

2018-09-25T22:47:25+00:00

commit 7992c18810e568b95c869b227137a2215702a805 upstream.

CVE-2018-9363

The buffer length is unsigned at all layers, but gets cast to int and
checked in hidp_process_report and can lead to a buffer overflow.
Switch len parameter to unsigned int to resolve issue.

This affects 3.18 and newer kernels.

Signed-off-by: Mark Salyzyn 
Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
Cc: Marcel Holtmann 
Cc: Johan Hedberg 
Cc: "David S. Miller" 
Cc: Kees Cook 
Cc: Benjamin Tissoires 
Cc: linux-bluetooth@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: security@kernel.org
Cc: kernel-team@android.com
Acked-by: Kees Cook 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

2018-06-16T21:21:29+00:00

commit 51bda2bca53b265715ca1852528f38dc67429d9a upstream.

it's OK after we'd verified the sockets, but not before that.

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

Bluetooth: Prevent stack info leak from the EFS element.

2018-02-13T18:42:31+00:00

commit 06e7e776ca4d36547e503279aeff996cbb292c16 upstream.

In the function l2cap_parse_conf_rsp and in the function
l2cap_parse_conf_req the following variable is declared without
initialization:

struct l2cap_conf_efs efs;

In addition, when parsing input configuration parameters in both of
these functions, the switch case for handling EFS elements may skip the
memcpy call that will write to the efs variable:

...
case L2CAP_CONF_EFS:
if (olen == sizeof(efs))
memcpy(&efs, (void *)val, olen);
...

The olen in the above if is attacker controlled, and regardless of that
if, in both of these functions the efs variable would eventually be
added to the outgoing configuration request that is being built:

l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs);

So by sending a configuration request, or response, that contains an
L2CAP_CONF_EFS element, but with an element length that is not
sizeof(efs) - the memcpy to the uninitialized efs variable can be
avoided, and the uninitialized variable would be returned to the
attacker (16 bytes).

This issue has been assigned CVE-2017-1000410

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: Ben Seri 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

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