linux-stable.git/net/bluetooth/hidp, branch linux-4.4.y

HID: introduce hid_is_using_ll_driver

2021-12-14T09:03:48+00:00

commit fc2237a724a9e448599076d7d23497f51e2f7441 upstream.

Although HID itself is transport-agnostic, occasionally a driver may
want to interact with the low-level transport that a device is connected
through. To do this, we need to know what kind of bus is in use. The
first guess may be to look at the 'bus' field of the 'struct hid_device',
but this field may be emulated in some cases (e.g. uhid).

More ideally, we can check which ll_driver a device is using. This
function introduces a 'hid_is_using_ll_driver' function and makes the
'struct hid_ll_driver' of the four most common transports accessible
through hid.h.

Signed-off-by: Jason Gerecke 
Acked-By: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hidp: use correct wait queue when removing ctrl_wait

2021-08-26T12:37:50+00:00

[ Upstream commit cca342d98bef68151a80b024f7bf5f388d1fbdea ]

A different wait queue was used when removing ctrl_wait than when adding
it. This effectively made the remove operation without locking compared
to other operations on the wait queue ctrl_wait was part of. This caused
issues like below where dead000000000100 is LIST_POISON1 and
dead000000000200 is LIST_POISON2.

 list_add corruption. next->prev should be prev (ffffffc1b0a33a08), \
	but was dead000000000200. (next=ffffffc03ac77de0).
 ------------[ cut here ]------------
 CPU: 3 PID: 2138 Comm: bluetoothd Tainted: G           O    4.4.238+ #9
 ...
 ---[ end trace 0adc2158f0646eac ]---
 Call trace:
 [] __list_add+0x38/0xb0
 [] add_wait_queue+0x4c/0x68
 [] __pollwait+0xec/0x100
 [] bt_sock_poll+0x74/0x200
 [] sock_poll+0x110/0x128
 [] do_sys_poll+0x220/0x480
 [] SyS_poll+0x80/0x138
 [] __sys_trace_return+0x0/0x4

 Unable to handle kernel paging request at virtual address dead000000000100
 ...
 CPU: 4 PID: 5387 Comm: kworker/u15:3 Tainted: G        W  O    4.4.238+ #9
 ...
 Call trace:
  [] __wake_up_common+0x7c/0xa8
  [] __wake_up+0x50/0x70
  [] sock_def_wakeup+0x58/0x60
  [] l2cap_sock_teardown_cb+0x200/0x224
  [] l2cap_chan_del+0xa4/0x298
  [] l2cap_conn_del+0x118/0x198
  [] l2cap_disconn_cfm+0x6c/0x78
  [] hci_event_packet+0x564/0x2e30
  [] hci_rx_work+0x10c/0x360
  [] process_one_work+0x268/0x460
  [] worker_thread+0x268/0x480
  [] kthread+0x118/0x128
  [] ret_from_fork+0x10/0x20
  ---[ end trace 0adc2158f0646ead ]---

Signed-off-by: Ole Bjørn Midtbø 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin

Bluetooth: hidp: fix buffer overflow

2019-05-16T17:45:04+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 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

Bluetooth: hidp: Fix handling of strncpy for hid->name information

2018-09-19T20:48:58+00:00

[ Upstream commit b3cadaa485f0c20add1644a5c877b0765b285c0c ]

This fixes two issues with setting hid->name information.

  CC      net/bluetooth/hidp/core.o
In function ‘hidp_setup_hid’,
    inlined from ‘hidp_session_dev_init’ at net/bluetooth/hidp/core.c:815:9,
    inlined from ‘hidp_session_new’ at net/bluetooth/hidp/core.c:953:8,
    inlined from ‘hidp_connection_add’ at net/bluetooth/hidp/core.c:1366:8:
net/bluetooth/hidp/core.c:778:2: warning: ‘strncpy’ output may be truncated copying 127 bytes from a string of length 127 [-Wstringop-truncation]
  strncpy(hid->name, req->name, sizeof(req->name) - 1);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  CC      net/bluetooth/hidp/core.o
net/bluetooth/hidp/core.c: In function ‘hidp_setup_hid’:
net/bluetooth/hidp/core.c:778:38: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Wsizeof-pointer-memaccess]
  strncpy(hid->name, req->name, sizeof(req->name));
                                      ^

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

Bluetooth: hidp: buffer overflow in hidp_process_report

2018-08-17T18:56:45+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: 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: hidp: fix device disconnect on idle timeout

2015-10-20T22:49:23+00:00

The HIDP specs define an idle-timeout which automatically disconnects a
device. This has always been implemented in the HIDP layer and forced a
synchronous shutdown of the hidp-scheduler. This works just fine, but
lacks a forced disconnect on the underlying l2cap channels. This has been
broken since:

    commit 5205185d461d5902325e457ca80bd421127b7308
    Author: David Herrmann 
    Date:   Sat Apr 6 20:28:47 2013 +0200

        Bluetooth: hidp: remove old session-management

The old session-management always forced an l2cap error on the ctrl/intr
channels when shutting down. The new session-management skips this, as we
don't want to enforce channel policy on the caller. In other words, if
user-space removes an HIDP device, the underlying channels (which are
*owned* and *referenced* by user-space) are still left active. User-space
needs to call shutdown(2) or close(2) to release them.

Unfortunately, this does not work with idle-timeouts. There is no way to
signal user-space that the HIDP layer has been stopped. The API simply
does not support any event-passing except for poll(2). Hence, we restore
old behavior and force EUNATCH on the sockets if the HIDP layer is
disconnected due to idle-timeouts (behavior of explicit disconnects
remains unmodified). User-space can still call

    getsockopt(..., SO_ERROR, ...)

..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
still be re-used (which nobody does so far, though). Therefore, the API
still supports the new behavior, but with this patch it's also compatible
to the old implicit channel shutdown.

Cc:  # 3.10+
Reported-by: Mark Haun 
Reported-by: Luiz Augusto von Dentz 
Signed-off-by: David Herrmann 
Signed-off-by: Marcel Holtmann

bluetooth: fix list handling

2015-07-05T02:11:33+00:00

Commit 835a6a2f8603 ("Bluetooth: Stop sabotaging list poisoning")
thought that the code was sabotaging the list poisoning when NULL'ing
out the list pointers and removed it.

But what was going on was that the bluetooth code was using NULL
pointers for the list as a way to mark it empty, and that commit just
broke it (and replaced the test with NULL with a "list_empty()" test on
a uninitialized list instead, breaking things even further).

So fix it all up to use the regular and real list_empty() handling
(which does not use NULL, but a pointer to itself), also making sure to
initialize the list properly (the previous NULL case was initialized
implicitly by the session being allocated with kzalloc())

This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
An.

[ I would normally expect to get this through the bt tree, but I'm going
  to release -rc1, so I'm just committing this directly   - Linus ]

Reported-and-tested-by: Jörg Otte 
Cc: Alexey Dobriyan 
Original-by: Tedd Ho-Jeong An 
Original-by: Marcel Holtmann :
Signed-off-by: Linus Torvalds

net: Pass kern from net_proto_family.create to sk_alloc

2015-05-11T14:50:17+00:00

In preparation for changing how struct net is refcounted
on kernel sockets pass the knowledge that we are creating
a kernel socket from sock_create_kern through to sk_alloc.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller

Bluetooth: hidp: Fix regression with older userspace and flags validation

2015-04-18T15:01:08+00:00

While it is not used by newer userspace anymore, the older userspace was
utilizing HIDP_VIRTUAL_CABLE_UNPLUG and HIDP_BOOT_PROTOCOL_MODE flags
when adding a new HIDP connection.

The flags validation is important, but we can not break older userspace
and with that allow providing these flags even if newer userspace does
not use them anymore.

Reported-and-tested-by: Jörg Otte 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds