linux-stable.git/net/bluetooth, branch linux-3.16.y

Bluetooth: delete a stray unlock

2020-02-11T20:03:44+00:00

commit df66499a1fab340c167250a5743931dc50d5f0fa upstream.

We used to take a lock in amp_physical_cfm() but then we moved it to
the caller function.  Unfortunately the unlock on this error path was
overlooked so it leads to a double unlock.

Fixes: a514b17fab51 ("Bluetooth: Refactor locking in amp_physical_cfm")
Signed-off-by: Dan Carpenter 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: hci_core: fix init for HCI_USER_CHANNEL

2020-02-11T20:03:18+00:00

commit eb8c101e28496888a0dcfe16ab86a1bee369e820 upstream.

During the setup() stage, HCI device drivers expect the chip to
acknowledge its setup() completion via vendor specific frames.

If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
the vendor specific frames are never tranmitted to the driver, as
they are filtered in hci_rx_work().

Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
frames if the HCI device is is HCI_INIT state.

[1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html

Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user operation")
Signed-off-by: Mattijs Korpershoek 
Signed-off-by: Marcel Holtmann 
[bwh: Backported to 3.16: Keep checking both HCI_RAW and HCI_USER_CHANNEL
 bits here]
Signed-off-by: Ben Hutchings

Bluetooth: Fix faulty expression for minimum encryption key size check

2019-09-23T20:11:51+00:00

commit eca94432934fe5f141d084f2e36ee2c0e614cc04 upstream.

Fix minimum encryption key size check so that HCI_MIN_ENC_KEY_SIZE is
also allowed as stated in the comment.

This bug caused connection problems with devices having maximum
encryption key size of 7 octets (56-bit).

Fixes: 693cd8ce3f88 ("Bluetooth: Fix regression with minimum encryption key size alignment")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203997
Signed-off-by: Matias Karhumaa 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

Bluetooth: Fix regression with minimum encryption key size alignment

2019-09-23T20:11:51+00:00

commit 693cd8ce3f882524a5d06f7800dd8492411877b3 upstream.

When trying to align the minimum encryption key size requirement for
Bluetooth connections, it turns out doing this in a central location in
the HCI connection handling code is not possible.

Original Bluetooth version up to 2.0 used a security model where the
L2CAP service would enforce authentication and encryption.  Starting
with Bluetooth 2.1 and Secure Simple Pairing that model has changed into
that the connection initiator is responsible for providing an encrypted
ACL link before any L2CAP communication can happen.

Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and
before devices are causing a regression.  The encryption key size check
needs to be moved out of the HCI connection handling into the L2CAP
channel setup.

To achieve this, the current check inside hci_conn_security() has been
moved into l2cap_check_enc_key_size() helper function and then called
from four decisions point inside L2CAP to cover all combinations of
Secure Simple Pairing enabled devices and device using legacy pairing
and legacy service security model.

Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16:
 - Encryption flag is in hci_conn::link_mode not hci_conn::flags
 - Adjust context, indentation]
Signed-off-by: Ben Hutchings

Bluetooth: Align minimum encryption key size for LE and BR/EDR connections

2019-09-23T20:11:50+00:00

commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.

The minimum encryption key size for LE connections is 56 bits and to
align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
BR/EDR connections as well.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Signed-off-by: Ben Hutchings

Bluetooth: hidp: fix buffer overflow

2019-06-20T17:11:27+00:00

commit a1616a5ac99ede5d605047a9012481ce7ff18b16 upstream.

Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.

This vulnerability is similar to CVE-2011-1079.

Signed-off-by: Young Xiao 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt

2019-05-02T20:42:03+00:00

commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream.

When doing option parsing for standard type values of 1, 2 or 4 octets,
the value is converted directly into a variable instead of a pointer. To
avoid being tricked into being a pointer, check that for these option
types that sizes actually match. In L2CAP every option is fixed size and
thus it is prudent anyway to ensure that the remote side sends us the
right option size along with option paramters.

If the option size is not matching the option type, then that option is
silently ignored. It is a protocol violation and instead of trying to
give the remote attacker any further hints just pretend that option is
not present and proceed with the default values. Implementation
following the specification and its qualification procedures will always
use the correct size and thus not being impacted here.

To keep the code readable and consistent accross all options, a few
cosmetic changes were also required.

Signed-off-by: Marcel Holtmann 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hedberg 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer

2019-05-02T20:42:03+00:00

commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream.

The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
as length value. The opt->len however is in control over the remote user
and can be used by an attacker to gain access beyond the bounds of the
actual packet.

To prevent any potential leak of heap memory, it is enough to check that
the resulting len calculation after calling l2cap_get_conf_opt is not
below zero. A well formed packet will always return >= 0 here and will
end with the length value being zero after the last option has been
parsed. In case of malformed packets messing with the opt->len field the
length value will become negative. If that is the case, then just abort
and ignore the option.

In case an attacker uses a too short opt->len value, then garbage will
be parsed, but that is protected by the unknown option handling and also
the option parameter size checks.

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

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