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

Bluetooth: Fix handling of unexpected SMP PDUs

2013-02-14T18:48:00+00:00

commit 8cf9fa1240229cbdd888236c0c43fcbad680cf00 upstream.

The conn->smp_chan pointer can be NULL if SMP PDUs arrive at unexpected
moments. To avoid NULL pointer dereferences the code should be checking
for this and disconnect if an unexpected SMP PDU arrives. This patch
fixes the issue by adding a check for conn->smp_chan for all other PDUs
except pairing request and security request (which are are the first
PDUs to come to initialize the SMP context).

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

Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

2013-02-04T00:27:04+00:00

commit 0a9ab9bdb3e891762553f667066190c1d22ad62b upstream.

The length parameter should be sizeof(req->name) - 1 because there is no
guarantee that string provided by userspace will contain the trailing
'\0'.

Can be easily reproduced by manually setting req->name to 128 non-zero
bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
input subsystem:

$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af

("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
field in struct hid_device due to overflow.)

Signed-off-by: Anderson Lizardo 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix sending HCI commands after reset

2013-02-04T00:27:00+00:00

commit dbccd791a3fbbdac12c33834b73beff3984988e9 upstream.

After sending reset command wait for its command complete event before
sending next command. Some chips sends CC event for command received
before reset if reset was send before chip replied with CC.

This is also required by specification that host shall not send
additional HCI commands before receiving CC for reset.

< HCI Command: Reset (0x03|0x0003) plen 0                              [hci0] 18.404612
> HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.405850
      Write Extended Inquiry Response (0x03|0x0052) ncmd 1
        Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.406079
> HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.407864
      Reset (0x03|0x0003) ncmd 1
        Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.408062
> HCI Event: Command Complete (0x0e) plen 12                           [hci0] 18.408835

Signed-off-by: Szymon Janc 
Acked-by: Johan Hedberg 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Revert "Bluetooth: Fix possible deadlock in SCO code"

2013-01-11T17:19:04+00:00

commit 0b27a4b97cb1874503c78453c0903df53c0c86b2 upstream.

This reverts commit 269c4845d5b3627b95b1934107251bacbe99bb68.

The commit was causing dead locks and NULL dereferences in the sco code:

 [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7]
 [28084.104021] Modules linked in: btusb bluetooth ] _raw_spin_lock+0xd/0x10
 [28084.104021]  [] sco_conn_del+0x58/0x1b0 [bluetooth]
 [28084.104021]  [] sco_connect_cfm+0xb9/0x2b0 [bluetooth]
 [28084.104021]  []
hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth]
 [28084.104021]  [] hci_event_packet+0x74d/0x2b40 [bluetooth]
 [28084.104021]  [] ? __kfree_skb+0x3d/0x90
 [28084.104021]  [] ? kfree_skb+0x36/0x90
 [28084.104021]  [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
 [28084.104021]  [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]

Reported-by: Chan-yeol Park 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: cancel power_on work when unregistering the device

2013-01-11T17:19:03+00:00

commit b9b5ef188e5a2222cfc16ef62a4703080750b451 upstream.

We need to cancel the hci_power_on work in order to avoid it run when we
try to free the hdev.

[ 1434.201149] ------------[ cut here ]------------
[ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
[ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
_power_on+0x0/0x90
[ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G        W    3.7.0-rc5-next-
20121112-sasha-00018-g2f4ce0e #127
[ 1434.210760] Call Trace:
[ 1434.210760]  [] ? debug_print_object+0x8e/0xb0
[ 1434.210760]  [] warn_slowpath_common+0x87/0xb0
[ 1434.210760]  [] warn_slowpath_fmt+0x41/0x50
[ 1434.210760]  [] debug_print_object+0x8e/0xb0
[ 1434.210760]  [] ? hci_dev_open+0x310/0x310
[ 1434.210760]  [] ? _raw_spin_unlock_irqrestore+0x55/0xa0
[ 1434.210760]  [] __debug_check_no_obj_freed+0xa5/0x230
[ 1434.210760]  [] ? bt_host_release+0x10/0x20
[ 1434.210760]  [] debug_check_no_obj_freed+0x15/0x20
[ 1434.210760]  [] kfree+0x227/0x330
[ 1434.210760]  [] bt_host_release+0x10/0x20
[ 1434.210760]  [] device_release+0x65/0xc0
[ 1434.210760]  [] kobject_cleanup+0x145/0x190
[ 1434.210760]  [] kobject_release+0xd/0x10
[ 1434.210760]  [] kobject_put+0x4c/0x60
[ 1434.210760]  [] put_device+0x12/0x20
[ 1434.210760]  [] hci_free_dev+0x24/0x30
[ 1434.210760]  [] vhci_release+0x31/0x60
[ 1434.210760]  [] __fput+0x122/0x250
[ 1434.210760]  [] ? rcu_user_exit+0x9d/0xd0
[ 1434.210760]  [] ____fput+0x9/0x10
[ 1434.210760]  [] task_work_run+0xb2/0xf0
[ 1434.210760]  [] do_notify_resume+0x77/0xa0
[ 1434.210760]  [] int_signal+0x12/0x17
[ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---

Reported-by: Sasha Levin 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Add missing lock nesting notation

2013-01-11T17:19:03+00:00

commit dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 upstream.

This patch fixes the following report, it happens when accepting rfcomm
connections:

[  228.165378] =============================================
[  228.165378] [ INFO: possible recursive locking detected ]
[  228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G        W
[  228.165378] ---------------------------------------------
[  228.165378] bluetoothd/1341 is trying to acquire lock:
[  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[  228.165378]
[  228.165378] but task is already holding lock:
[  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[  228.165378]
[  228.165378] other info that might help us debug this:
[  228.165378]  Possible unsafe locking scenario:
[  228.165378]
[  228.165378]        CPU0
[  228.165378]        ----
[  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[  228.165378]
[  228.165378]  *** DEADLOCK ***
[  228.165378]
[  228.165378]  May be due to missing lock nesting notation

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

Bluetooth: Fix memory leak when removing a UUID

2012-11-09T15:45:37+00:00

When removing a UUID from the list in the remove_uuid() function we must
also kfree the entry in addition to removing it from the list.

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

Bluetooth: Notify about device registration before power on

2012-11-09T15:45:37+00:00

It is important that the monitor interface gets notified about
a new device before its power on procedure has been started.

For some reason that is no longer working as expected and the power
on procedure runs first. It is safe to just notify about device
registration and trigger the power on procedure afterwards.

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

Bluetooth: Fix error status when pairing fails

2012-11-09T15:45:37+00:00

When pairing fails due to wrong confirm value, the management layer
doesn't report a proper error status. It sends
MGMT_STATUS_CONNECT_FAILED instead of MGMT_STATUS_AUTH_FAILED.

Most of management functions that receive a status as a parameter
expects for it to be encoded as a HCI status. But when a SMP pairing
fails, the SMP layer sends the SMP reason as the error status to the
management layer.

This commit maps all SMP reasons to HCI_ERROR_AUTH_FAILURE, which will
be converted to MGMT_STATUS_AUTH_FAILED in the management layer.

Reported-by: Claudio Takahasi 
Reviewed-by: João Paulo Rechi Vita 
Signed-off-by: Paulo Sérgio 
Signed-off-by: Gustavo Padovan

Bluetooth: Fix having bogus entries in mgmt_read_index_list reply

2012-11-09T15:45:37+00:00

The mgmt_read_index_list uses one loop to calculate the max needed size
of its response with the help of an upper-bound of the controller count.
The second loop is more strict as it checks for HCI_SETUP (which might
have gotten set after the first loop) and could result in some indexes
being skipped. Because of this the function needs to readjust the event
length and index count after filling in the response array.

Signed-off-by: Johan Hedberg 
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo Padovan