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

Bluetooth: Fix rfkill functionality during the HCI setup stage

2013-10-14T01:14:29+00:00

commit bf5430360ebe4b2d0c51d91f782e649107b502eb upstream.

We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).

This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.

The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.

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

Bluetooth: Introduce a new HCI_RFKILLED flag

2013-10-14T01:14:29+00:00

commit 5e130367d43ff22836bbae380d197d600fe8ddbb upstream.

This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.

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

Bluetooth: Fix encryption key size for peripheral role

2013-10-14T01:14:28+00:00

commit 89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream.

This patch fixes the connection encryption key size information when
the host is playing the peripheral role. We should set conn->enc_key_
size in hci_le_ltk_request_evt, otherwise it is left uninitialized.

Signed-off-by: Andre Guedes 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix security level for peripheral role

2013-10-14T01:14:28+00:00

commit f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream.

While playing the peripheral role, the host gets a LE Long Term Key
Request Event from the controller when a connection is established
with a bonded device. The host then informs the LTK which should be
used for the connection. Once the link is encrypted, the host gets
an Encryption Change Event.

Therefore we should set conn->pending_sec_level instead of conn->
sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
properly updated in hci_encrypt_change_evt.

Moreover, since we have a LTK associated to the device, we have at
least BT_SECURITY_MEDIUM security level.

Signed-off-by: Andre Guedes 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

HID: fix unused rsize usage

2013-10-14T01:14:23+00:00

commit bc197eedef1ae082ec662c64c3f4aa302821fb7a upstream.

27ce4050 ("HID: fix data access in implement()") by mistake removed
a setting of buffer size in hidp. Fix that by putting it back.

Reported-by: kbuild test robot 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: fix data access in implement()

2013-10-14T01:14:23+00:00

commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream.

implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.

This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.

This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:

  http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html

I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.

I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().

All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.

Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.

Reviewed-by: Benjamin Tissoires 
Acked-by: Gustavo Padovan 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth

2013-07-31T19:11:50+00:00

Conflicts:
	net/bluetooth/hci_core.c

Bluetooth: Fix calling request callback more than once

2013-07-29T11:28:04+00:00

In certain circumstances, such as an HCI driver using __hci_cmd_sync_ev
with HCI_EV_CMD_COMPLETE as the expected completion event there is the
chance that hci_event_packet will call hci_req_cmd_complete twice (once
for the explicitly looked after event and another time in the actual
handler of cmd_complete).

In the case of __hci_cmd_sync_ev this introduces a race where the first
call wakes up the blocking __hci_cmd_sync_ev and lets it complete.
However, by the time that a second __hci_cmd_sync_ev call is already in
progress the second hci_req_cmd_complete call (from the previous
operation) will wake up the blocking function prematurely and cause it
to fail, as witnessed by the following log:

[  639.232195] hci_rx_work: hci0 Event packet
[  639.232201] hci_req_cmd_complete: opcode 0xfc8e status 0x00
[  639.232205] hci_sent_cmd_data: hci0 opcode 0xfc8e
[  639.232210] hci_req_sync_complete: hci0 result 0x00
[  639.232220] hci_cmd_complete_evt: hci0 opcode 0xfc8e
[  639.232225] hci_req_cmd_complete: opcode 0xfc8e status 0x00
[  639.232228] __hci_cmd_sync_ev: hci0 end: err 0
[  639.232234] __hci_cmd_sync_ev: hci0
[  639.232238] hci_req_add_ev: hci0 opcode 0xfc8e plen 250
[  639.232242] hci_prepare_cmd: skb len 253
[  639.232246] hci_req_run: length 1
[  639.232250] hci_sent_cmd_data: hci0 opcode 0xfc8e
[  639.232255] hci_req_sync_complete: hci0 result 0x00
[  639.232266] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1
[  639.232271] __hci_cmd_sync_ev: hci0 end: err 0
[  639.232276] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-61)

Signed-off-by: Johan Hedberg 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo Padovan

Bluetooth: Fix HCI init for BlueFRITZ! devices

2013-07-29T11:12:27+00:00

None of the BlueFRITZ! devices with manufacurer ID 31 (AVM Berlin)
support HCI_Read_Local_Supported_Commands. It is safe to use the
manufacturer ID (instead of e.g. a USB ID specific quirk) because the
company never created any newer controllers.

< HCI Command: Read Local Supported Comm.. (0x04|0x0002) plen 0 [hci0] 0.210014
> HCI Event: Command Status (0x0f) plen 4 [hci0] 0.217361
      Read Local Supported Commands (0x04|0x0002) ncmd 1
        Status: Unknown HCI Command (0x01)

Reported-by: Jörg Esser 
Signed-off-by: Johan Hedberg 
Tested-by: Jörg Esser 
Signed-off-by: Gustavo Padovan

Bluetooth: Fix race between hci_register_dev() and hci_dev_open()

2013-07-25T18:52:36+00:00

If hci_dev_open() is called after hci_register_dev() added the device to
the hci_dev_list but before the workqueue are created we could run into a
NULL pointer dereference (see below).

This bug is very unlikely to happen, systems using bluetoothd to
manage their bluetooth devices will never see this happen.

BUG: unable to handle kernel NULL pointer dereference
0100
IP: [] __queue_work+0x32/0x3d0
(...)
Call Trace:
 [] queue_work_on+0x45/0x50
 [] hci_req_run+0xbf/0xf0 [bluetooth]
 [] ? hci_init2_req+0x720/0x720 [bluetooth]
 [] __hci_req_sync+0xd6/0x1c0 [bluetooth]
 [] ? try_to_wake_up+0x2b0/0x2b0
 [] ? usb_autopm_put_interface+0x30/0x40
 [] hci_dev_open+0x275/0x2e0 [bluetooth]
 [] hci_sock_ioctl+0x1f2/0x3f0 [bluetooth]
 [] sock_do_ioctl+0x30/0x70
 [] sock_ioctl+0x79/0x2f0
 [] do_vfs_ioctl+0x96/0x560
 [] SyS_ioctl+0x91/0xb0
 [] system_call_fastpath+0x1a/0x1f

Reported-by: Sedat Dilek 
Signed-off-by: Gustavo Padovan