linux-toradex.git/net/bluetooth, branch v3.4.34

Bluetooth: Fix handling of unexpected SMP PDUs

2013-02-14T18:48:53+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:24:41+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:24:40+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

Bluetooth: cancel power_on work when unregistering the device

2013-01-11T17:07:17+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:07:17+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 using uninitialized option in RFCMode

2012-12-03T19:46:36+00:00

commit 8f321f853ea33330c7141977cd34804476e2e07e upstream.

If remote device sends bogus RFC option with invalid length,
undefined options values are used. Fix this by using defaults when
remote misbehaves.

This also fixes the following warning reported by gcc 4.7.0:

net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here
net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here
net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here
net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here

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

Bluetooth: SMP: Fix setting unknown auth_req bits

2012-10-31T17:03:02+00:00

commit 065a13e2cc665f6547dc7e8a9d6b6565badf940a upstream.

When sending a pairing request or response we should not just blindly
copy the value that the remote device sent. Instead we should at least
make sure to mask out any unknown bits. This is particularly critical
from the upcoming LE Secure Connections feature perspective as
incorrectly indicating support for it (by copying the remote value)
would cause a failure to pair with devices that support it.

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

Bluetooth: Fix sending a HCI Authorization Request over LE links

2012-10-02T17:30:34+00:00

commit d8343f125710fb596f7a88cd756679f14f4e77b9 upstream.

In the case that the link is already in the connected state and a
Pairing request arrives from the mgmt interface, hci_conn_security()
would be called but it was not considering LE links.

Reported-by: João Paulo Rechi Vita 
Signed-off-by: Vinicius Costa Gomes 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Change signature of smp_conn_security()

2012-10-02T17:30:34+00:00

commit cc110922da7e902b62d18641a370fec01a9fa794 upstream.

To make it clear that it may be called from contexts that may not have
any knowledge of L2CAP, we change the connection parameter, to receive
a hci_conn.

This also makes it clear that it is checking the security of the link.

Signed-off-by: Vinicius Costa Gomes 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix use-after-free bug in SMP

2012-10-02T17:30:34+00:00

commit 61a0cfb008f57ecf7eb28ee762952fb42dc15d15 upstream.

If SMP fails, we should always cancel security_timer delayed work.
Otherwise, security_timer function may run after l2cap_conn object
has been freed.

This patch fixes the following warning reported by ODEBUG:

WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
Hardware name: Bochs
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27
Modules linked in: btusb bluetooth
Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4
Call Trace:
 [] ? free_obj_work+0x4a/0x7f
 [] warn_slowpath_common+0x7e/0x97
 [] warn_slowpath_fmt+0x41/0x43
 [] debug_print_object+0x7c/0x8d
 [] ? __queue_work+0x241/0x241
 [] debug_check_no_obj_freed+0x92/0x159
 [] slab_free_hook+0x6f/0x77
 [] ? l2cap_conn_del+0x148/0x157 [bluetooth]
 [] kfree+0x59/0xac
 [] l2cap_conn_del+0x148/0x157 [bluetooth]
 [] l2cap_recv_frame+0xa77/0xfa4 [bluetooth]
 [] ? trace_hardirqs_on_caller+0x112/0x1ad
 [] l2cap_recv_acldata+0xe2/0x264 [bluetooth]
 [] hci_rx_work+0x235/0x33c [bluetooth]
 [] ? process_one_work+0x126/0x2fe
 [] process_one_work+0x185/0x2fe
 [] ? process_one_work+0x126/0x2fe
 [] ? lock_acquired+0x1b5/0x1cf
 [] ? le_scan_work+0x11d/0x11d [bluetooth]
 [] ? spin_lock_irq+0x9/0xb
 [] worker_thread+0xcf/0x175
 [] ? rescuer_thread+0x175/0x175
 [] kthread+0x95/0x9d
 [] kernel_threadi_helper+0x4/0x10
 [] ? retint_restore_args+0x13/0x13
 [] ? flush_kthread_worker+0xdb/0xdb
 [] ? gs_change+0x13/0x13

This bug can be reproduced using hctool lecc or l2test tools and
bluetoothd not running.

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