<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/bluetooth, branch linux-3.8.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Bluetooth: SCO - Fix missing msg_namelen update in sco_sock_recvmsg()</title>
<updated>2013-05-01T16:46:01+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2013-04-07T01:51:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=95fb8027002f3c92e35b03a825abc131f744114c'/>
<id>95fb8027002f3c92e35b03a825abc131f744114c</id>
<content type='text'>
[ Upstream commit c8c499175f7d295ef867335bceb9a76a2c3cdc38 ]

If the socket is in state BT_CONNECT2 and BT_SK_DEFER_SETUP is set in
the flags, sco_sock_recvmsg() returns early with 0 without updating the
possibly set msg_namelen member. This, in turn, leads to a 128 byte
kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_recvmsg().

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c8c499175f7d295ef867335bceb9a76a2c3cdc38 ]

If the socket is in state BT_CONNECT2 and BT_SK_DEFER_SETUP is set in
the flags, sco_sock_recvmsg() returns early with 0 without updating the
possibly set msg_namelen member. This, in turn, leads to a 128 byte
kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_recvmsg().

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()</title>
<updated>2013-05-01T16:46:01+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2013-04-07T01:51:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c81ed3c15cf8c345f7cd78428fdc4bc745f45bbf'/>
<id>c81ed3c15cf8c345f7cd78428fdc4bc745f45bbf</id>
<content type='text'>
[ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]

If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
early with 0 without updating the possibly set msg_namelen member. This,
in turn, leads to a 128 byte kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_stream_recvmsg().

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]

If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
early with 0 without updating the possibly set msg_namelen member. This,
in turn, leads to a 128 byte kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_stream_recvmsg().

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: fix possible info leak in bt_sock_recvmsg()</title>
<updated>2013-05-01T16:46:01+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2013-04-07T01:51:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8244d9fcae39a13ec99f85a9eaf8956b25341ae1'/>
<id>8244d9fcae39a13ec99f85a9eaf8956b25341ae1</id>
<content type='text'>
[ Upstream commit 4683f42fde3977bdb4e8a09622788cc8b5313778 ]

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4683f42fde3977bdb4e8a09622788cc8b5313778 ]

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Cc: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: Gustavo Padovan &lt;gustavo@padovan.org&gt;
Cc: Johan Hedberg &lt;johan.hedberg@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix not closing SCO sockets in the BT_CONNECT2 state</title>
<updated>2013-04-05T16:25:45+00:00</updated>
<author>
<name>Vinicius Costa Gomes</name>
<email>vinicius.gomes@openbossa.org</email>
</author>
<published>2013-03-13T22:46:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e386b9a46fce2d33c8eeae9883763524e0ba2a7a'/>
<id>e386b9a46fce2d33c8eeae9883763524e0ba2a7a</id>
<content type='text'>
commit eb20ff9c91ddcb2d55c1849a87d3db85af5e88a9 upstream.

With deferred setup for SCO, it is possible that userspace closes the
socket when it is in the BT_CONNECT2 state, after the Connect Request is
received but before the Accept Synchonous Connection is sent.

If this happens the following crash was observed, when the connection is
terminated:

[  +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10
[  +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16
[  +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110
[  +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199
[  +0.000906] IP: [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0
[  +0.000000] Oops: 0002 [#1] SMP
[  +0.000000] Modules linked in: rfcomm bnep btusb bluetooth
[  +0.000000] CPU 0
[  +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd #1 Bochs Bochs
[  +0.000000] RIP: 0010:[&lt;ffffffff810620dd&gt;]  [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000] RSP: 0018:ffff88003c3c19d8  EFLAGS: 00010002
[  +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000
[  +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868
[  +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000
[  +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002
[  +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850
[  +0.000000] FS:  0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
[  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0
[  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000)
[  +0.000000] Stack:
[  +0.000000]  ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868
[  +0.000000]  ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd
[  +0.000000]  0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a
[  +0.000000] Call Trace:
[  +0.000000]  [&lt;ffffffff8101efbd&gt;] ? kvm_clock_read+0x34/0x3b
[  +0.000000]  [&lt;ffffffff81007c7a&gt;] ? paravirt_sched_clock+0x9/0xd
[  +0.000000]  [&lt;ffffffff81007fd4&gt;] ? sched_clock+0x9/0xb
[  +0.000000]  [&lt;ffffffff8104fd7a&gt;] ? sched_clock_local+0x12/0x75
[  +0.000000]  [&lt;ffffffff810632d1&gt;] lock_acquire+0x93/0xb1
[  +0.000000]  [&lt;ffffffffa0022339&gt;] ? spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffff8105f3d8&gt;] ? lock_release_holdtime.part.22+0x4e/0x55
[  +0.000000]  [&lt;ffffffff814f6038&gt;] _raw_spin_lock+0x40/0x74
[  +0.000000]  [&lt;ffffffffa0022339&gt;] ? spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffff814f6936&gt;] ? _raw_spin_unlock+0x23/0x36
[  +0.000000]  [&lt;ffffffffa0022339&gt;] spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffffa00230cc&gt;] sco_conn_del+0x76/0xbb [bluetooth]
[  +0.000000]  [&lt;ffffffffa002391d&gt;] sco_connect_cfm+0x2da/0x2e9 [bluetooth]
[  +0.000000]  [&lt;ffffffffa000862a&gt;] hci_proto_connect_cfm+0x38/0x65 [bluetooth]
[  +0.000000]  [&lt;ffffffffa0008d30&gt;] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth]
[  +0.000000]  [&lt;ffffffffa000cd96&gt;] hci_event_packet+0x153b/0x239d [bluetooth]
[  +0.000000]  [&lt;ffffffff814f68ff&gt;] ? _raw_spin_unlock_irqrestore+0x48/0x5c
[  +0.000000]  [&lt;ffffffffa00025f6&gt;] hci_rx_work+0xf3/0x2e3 [bluetooth]
[  +0.000000]  [&lt;ffffffff8103efed&gt;] process_one_work+0x1dc/0x30b
[  +0.000000]  [&lt;ffffffff8103ef83&gt;] ? process_one_work+0x172/0x30b
[  +0.000000]  [&lt;ffffffff8103e07f&gt;] ? spin_lock_irq+0x9/0xb
[  +0.000000]  [&lt;ffffffff8103fc8d&gt;] worker_thread+0x123/0x1d2
[  +0.000000]  [&lt;ffffffff8103fb6a&gt;] ? manage_workers+0x240/0x240
[  +0.000000]  [&lt;ffffffff81044211&gt;] kthread+0x9d/0xa5
[  +0.000000]  [&lt;ffffffff81044174&gt;] ? __kthread_parkme+0x60/0x60
[  +0.000000]  [&lt;ffffffff814f75bc&gt;] ret_from_fork+0x7c/0xb0
[  +0.000000]  [&lt;ffffffff81044174&gt;] ? __kthread_parkme+0x60/0x60
[  +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 &lt;f0&gt; ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00
[  +0.000000] RIP  [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000]  RSP &lt;ffff88003c3c19d8&gt;
[  +0.000000] CR2: 0000000000000199
[  +0.000000] ---[ end trace e73cd3b52352dd34 ]---

Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@openbossa.org&gt;
Tested-by: Frederic Dalleau &lt;frederic.dalleau@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eb20ff9c91ddcb2d55c1849a87d3db85af5e88a9 upstream.

With deferred setup for SCO, it is possible that userspace closes the
socket when it is in the BT_CONNECT2 state, after the Connect Request is
received but before the Accept Synchonous Connection is sent.

If this happens the following crash was observed, when the connection is
terminated:

[  +0.000003] hci_sync_conn_complete_evt: hci0 status 0x10
[  +0.000005] sco_connect_cfm: hcon ffff88003d1bd800 bdaddr 40:98:4e:32:d7:39 status 16
[  +0.000003] sco_conn_del: hcon ffff88003d1bd800 conn ffff88003cc8e300, err 110
[  +0.000015] BUG: unable to handle kernel NULL pointer dereference at 0000000000000199
[  +0.000906] IP: [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000] PGD 3d21f067 PUD 3d291067 PMD 0
[  +0.000000] Oops: 0002 [#1] SMP
[  +0.000000] Modules linked in: rfcomm bnep btusb bluetooth
[  +0.000000] CPU 0
[  +0.000000] Pid: 1481, comm: kworker/u:2H Not tainted 3.9.0-rc1-25019-gad82cdd #1 Bochs Bochs
[  +0.000000] RIP: 0010:[&lt;ffffffff810620dd&gt;]  [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000] RSP: 0018:ffff88003c3c19d8  EFLAGS: 00010002
[  +0.000000] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000000
[  +0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d1be868
[  +0.000000] RBP: ffff88003c3c1a98 R08: 0000000000000002 R09: 0000000000000000
[  +0.000000] R10: ffff88003d1be868 R11: ffff88003e20b000 R12: 0000000000000002
[  +0.000000] R13: ffff88003aaa8000 R14: 000000000000006e R15: ffff88003d1be850
[  +0.000000] FS:  0000000000000000(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
[  +0.000000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  +0.000000] CR2: 0000000000000199 CR3: 000000003c1cb000 CR4: 00000000000006b0
[  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  +0.000000] Process kworker/u:2H (pid: 1481, threadinfo ffff88003c3c0000, task ffff88003aaa8000)
[  +0.000000] Stack:
[  +0.000000]  ffffffff81b16342 0000000000000000 0000000000000000 ffff88003d1be868
[  +0.000000]  ffffffff00000000 00018c0c7863e367 000000003c3c1a28 ffffffff8101efbd
[  +0.000000]  0000000000000000 ffff88003e3d2400 ffff88003c3c1a38 ffffffff81007c7a
[  +0.000000] Call Trace:
[  +0.000000]  [&lt;ffffffff8101efbd&gt;] ? kvm_clock_read+0x34/0x3b
[  +0.000000]  [&lt;ffffffff81007c7a&gt;] ? paravirt_sched_clock+0x9/0xd
[  +0.000000]  [&lt;ffffffff81007fd4&gt;] ? sched_clock+0x9/0xb
[  +0.000000]  [&lt;ffffffff8104fd7a&gt;] ? sched_clock_local+0x12/0x75
[  +0.000000]  [&lt;ffffffff810632d1&gt;] lock_acquire+0x93/0xb1
[  +0.000000]  [&lt;ffffffffa0022339&gt;] ? spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffff8105f3d8&gt;] ? lock_release_holdtime.part.22+0x4e/0x55
[  +0.000000]  [&lt;ffffffff814f6038&gt;] _raw_spin_lock+0x40/0x74
[  +0.000000]  [&lt;ffffffffa0022339&gt;] ? spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffff814f6936&gt;] ? _raw_spin_unlock+0x23/0x36
[  +0.000000]  [&lt;ffffffffa0022339&gt;] spin_lock+0x9/0xb [bluetooth]
[  +0.000000]  [&lt;ffffffffa00230cc&gt;] sco_conn_del+0x76/0xbb [bluetooth]
[  +0.000000]  [&lt;ffffffffa002391d&gt;] sco_connect_cfm+0x2da/0x2e9 [bluetooth]
[  +0.000000]  [&lt;ffffffffa000862a&gt;] hci_proto_connect_cfm+0x38/0x65 [bluetooth]
[  +0.000000]  [&lt;ffffffffa0008d30&gt;] hci_sync_conn_complete_evt.isra.79+0x11a/0x13e [bluetooth]
[  +0.000000]  [&lt;ffffffffa000cd96&gt;] hci_event_packet+0x153b/0x239d [bluetooth]
[  +0.000000]  [&lt;ffffffff814f68ff&gt;] ? _raw_spin_unlock_irqrestore+0x48/0x5c
[  +0.000000]  [&lt;ffffffffa00025f6&gt;] hci_rx_work+0xf3/0x2e3 [bluetooth]
[  +0.000000]  [&lt;ffffffff8103efed&gt;] process_one_work+0x1dc/0x30b
[  +0.000000]  [&lt;ffffffff8103ef83&gt;] ? process_one_work+0x172/0x30b
[  +0.000000]  [&lt;ffffffff8103e07f&gt;] ? spin_lock_irq+0x9/0xb
[  +0.000000]  [&lt;ffffffff8103fc8d&gt;] worker_thread+0x123/0x1d2
[  +0.000000]  [&lt;ffffffff8103fb6a&gt;] ? manage_workers+0x240/0x240
[  +0.000000]  [&lt;ffffffff81044211&gt;] kthread+0x9d/0xa5
[  +0.000000]  [&lt;ffffffff81044174&gt;] ? __kthread_parkme+0x60/0x60
[  +0.000000]  [&lt;ffffffff814f75bc&gt;] ret_from_fork+0x7c/0xb0
[  +0.000000]  [&lt;ffffffff81044174&gt;] ? __kthread_parkme+0x60/0x60
[  +0.000000] Code: d7 44 89 8d 50 ff ff ff 4c 89 95 58 ff ff ff e8 44 fc ff ff 44 8b 8d 50 ff ff ff 48 85 c0 4c 8b 95 58 ff ff ff 0f 84 7a 04 00 00 &lt;f0&gt; ff 80 98 01 00 00 83 3d 25 41 a7 00 00 45 8b b5 e8 05 00 00
[  +0.000000] RIP  [&lt;ffffffff810620dd&gt;] __lock_acquire+0xed/0xe82
[  +0.000000]  RSP &lt;ffff88003c3c19d8&gt;
[  +0.000000] CR2: 0000000000000199
[  +0.000000] ---[ end trace e73cd3b52352dd34 ]---

Signed-off-by: Vinicius Costa Gomes &lt;vinicius.gomes@openbossa.org&gt;
Tested-by: Frederic Dalleau &lt;frederic.dalleau@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix hci_conn timeout routine</title>
<updated>2013-01-31T17:38:02+00:00</updated>
<author>
<name>Andre Guedes</name>
<email>andre.guedes@openbossa.org</email>
</author>
<published>2013-01-30T14:50:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4c02e2d444595200d0b18b889994aac3611cd288'/>
<id>4c02e2d444595200d0b18b889994aac3611cd288</id>
<content type='text'>
If occurs a LE or SCO hci_conn timeout and the connection is already
established (BT_CONNECTED state), the connection is not terminated as
expected. This bug can be reproduced using l2test or scotest tool.
Once the connection is established, kill l2test/scotest and the
connection won't be terminated.

This patch fixes hci_conn_disconnect helper so it is able to
terminate LE and SCO connections, as well as ACL.

Signed-off-by: Andre Guedes &lt;andre.guedes@openbossa.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If occurs a LE or SCO hci_conn timeout and the connection is already
established (BT_CONNECTED state), the connection is not terminated as
expected. This bug can be reproduced using l2test or scotest tool.
Once the connection is established, kill l2test/scotest and the
connection won't be terminated.

This patch fixes hci_conn_disconnect helper so it is able to
terminate LE and SCO connections, as well as ACL.

Signed-off-by: Andre Guedes &lt;andre.guedes@openbossa.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix handling of unexpected SMP PDUs</title>
<updated>2013-01-31T17:35:42+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2013-01-29T16:44:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8cf9fa1240229cbdd888236c0c43fcbad680cf00'/>
<id>8cf9fa1240229cbdd888236c0c43fcbad680cf00</id>
<content type='text'>
The conn-&gt;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-&gt;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 &lt;johan.hedberg@intel.com&gt;
CC: stable@vger.kernel.org
Acked-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The conn-&gt;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-&gt;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 &lt;johan.hedberg@intel.com&gt;
CC: stable@vger.kernel.org
Acked-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Check if the hci connection exists in SCO shutdown</title>
<updated>2013-01-10T05:53:32+00:00</updated>
<author>
<name>Gustavo Padovan</name>
<email>gustavo.padovan@collabora.co.uk</email>
</author>
<published>2013-01-03T21:59:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b7e98b5100aad9290d7f06fcb9d1e80f7f62f05f'/>
<id>b7e98b5100aad9290d7f06fcb9d1e80f7f62f05f</id>
<content type='text'>
Checking only for sco_conn seems to not be enough and lead to NULL
dereferences in the code, check for hcon instead.

&lt;1&gt;[11340.226404] BUG: unable to handle kernel NULL pointer dereference at
0000000
8
&lt;4&gt;[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
&lt;4&gt;[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000
&lt;4&gt;[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c
&lt;0&gt;[11340.226674] Stack:
&lt;4&gt;[11340.226682]  c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00
00000000
e0fdff5c
&lt;4&gt;[11340.226718]  c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852
d7813800
62262f10
&lt;4&gt;[11340.226752]  e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac
c175425c
00000041
&lt;0&gt;[11340.226793] Call Trace:
&lt;4&gt;[11340.226813]  [&lt;c184db87&gt;] ? sco_sock_clear_timer+0x27/0x60
&lt;4&gt;[11340.226831]  [&lt;c1251028&gt;] ? local_bh_enable+0x68/0xd0
&lt;4&gt;[11340.226846]  [&lt;c1754aef&gt;] ? lock_sock_nested+0x4f/0x60
&lt;4&gt;[11340.226862]  [&lt;c184f587&gt;] sco_sock_shutdown+0x67/0xb0
&lt;4&gt;[11340.226879]  [&lt;c1751852&gt;] ? sockfd_lookup_light+0x22/0x80
&lt;4&gt;[11340.226897]  [&lt;c1753c00&gt;] sys_shutdown+0x30/0x60
&lt;4&gt;[11340.226912]  [&lt;c175425c&gt;] sys_socketcall+0x1dc/0x2a0
&lt;4&gt;[11340.226929]  [&lt;c149ba78&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
&lt;4&gt;[11340.226944]  [&lt;c18860f1&gt;] syscall_call+0x7/0xb
&lt;4&gt;[11340.226960]  [&lt;c1880000&gt;] ? restore_cur+0x5e/0xd7
&lt;0&gt;[11340.226969] Code: &lt;f0&gt; ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74
2f b8 0a 00 00

Reported-by: Chuansheng Liu &lt;chuansheng.liu@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Checking only for sco_conn seems to not be enough and lead to NULL
dereferences in the code, check for hcon instead.

&lt;1&gt;[11340.226404] BUG: unable to handle kernel NULL pointer dereference at
0000000
8
&lt;4&gt;[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
&lt;4&gt;[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000
&lt;4&gt;[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c
&lt;0&gt;[11340.226674] Stack:
&lt;4&gt;[11340.226682]  c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00
00000000
e0fdff5c
&lt;4&gt;[11340.226718]  c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852
d7813800
62262f10
&lt;4&gt;[11340.226752]  e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac
c175425c
00000041
&lt;0&gt;[11340.226793] Call Trace:
&lt;4&gt;[11340.226813]  [&lt;c184db87&gt;] ? sco_sock_clear_timer+0x27/0x60
&lt;4&gt;[11340.226831]  [&lt;c1251028&gt;] ? local_bh_enable+0x68/0xd0
&lt;4&gt;[11340.226846]  [&lt;c1754aef&gt;] ? lock_sock_nested+0x4f/0x60
&lt;4&gt;[11340.226862]  [&lt;c184f587&gt;] sco_sock_shutdown+0x67/0xb0
&lt;4&gt;[11340.226879]  [&lt;c1751852&gt;] ? sockfd_lookup_light+0x22/0x80
&lt;4&gt;[11340.226897]  [&lt;c1753c00&gt;] sys_shutdown+0x30/0x60
&lt;4&gt;[11340.226912]  [&lt;c175425c&gt;] sys_socketcall+0x1dc/0x2a0
&lt;4&gt;[11340.226929]  [&lt;c149ba78&gt;] ? trace_hardirqs_on_thunk+0xc/0x10
&lt;4&gt;[11340.226944]  [&lt;c18860f1&gt;] syscall_call+0x7/0xb
&lt;4&gt;[11340.226960]  [&lt;c1880000&gt;] ? restore_cur+0x5e/0xd7
&lt;0&gt;[11340.226969] Code: &lt;f0&gt; ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74
2f b8 0a 00 00

Reported-by: Chuansheng Liu &lt;chuansheng.liu@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix authentication if acl data comes before remote feature evt</title>
<updated>2013-01-10T05:26:18+00:00</updated>
<author>
<name>Jaganath Kanakkassery</name>
<email>jaganath.k@samsung.com</email>
</author>
<published>2013-01-10T04:58:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b064edae38d62d8587a8c574f93b53ce75ae749'/>
<id>7b064edae38d62d8587a8c574f93b53ce75ae749</id>
<content type='text'>
If remote device sends l2cap info request before read_remote_ext_feature
completes then mgmt_connected will be sent in hci_acldata_packet() and
remote name request wont be sent and eventually authentication wont happen

Hcidump log of the issue

&lt; HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
&gt; HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
&gt; HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
&lt; HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 12
&gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
&gt; HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 12
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
&gt; HCI Event: Max Slots Change (0x1b) plen 3
    handle 12 slots 5
&lt; HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
    handle 12 page 1
&gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
&gt; ACL data: handle 12 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
&lt; ACL data: handle 12 flags 0x00 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x00b8
        Enhanced Retransmission mode
        Streaming mode
        FCS Option
        Fixed Channels
&gt; HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 12 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
&gt; ACL data: handle 12 flags 0x02 dlen 10
    L2CAP(s): Info req: type 3
&lt; ACL data: handle 12 flags 0x00 dlen 20
    L2CAP(s): Info rsp: type 3 result 0
      Fixed channel list 0x00000002
        L2CAP Signalling Channel
&gt; HCI Event: Number of Completed Packets (0x13) plen 5
    handle 12 packets 2

This patch moves sending mgmt_connected from hci_acldata_packet() to
l2cap_connect_req() since this code is to handle the scenario remote
device sends l2cap connect req too fast

Signed-off-by: Jaganath Kanakkassery &lt;jaganath.k@samsung.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If remote device sends l2cap info request before read_remote_ext_feature
completes then mgmt_connected will be sent in hci_acldata_packet() and
remote name request wont be sent and eventually authentication wont happen

Hcidump log of the issue

&lt; HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid)
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
&gt; HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
&gt; HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00
&lt; HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 12
&gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
&gt; HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 12
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
&gt; HCI Event: Max Slots Change (0x1b) plen 3
    handle 12 slots 5
&lt; HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
    handle 12 page 1
&gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
&gt; ACL data: handle 12 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
&lt; ACL data: handle 12 flags 0x00 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x00b8
        Enhanced Retransmission mode
        Streaming mode
        FCS Option
        Fixed Channels
&gt; HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 12 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
&gt; ACL data: handle 12 flags 0x02 dlen 10
    L2CAP(s): Info req: type 3
&lt; ACL data: handle 12 flags 0x00 dlen 20
    L2CAP(s): Info rsp: type 3 result 0
      Fixed channel list 0x00000002
        L2CAP Signalling Channel
&gt; HCI Event: Number of Completed Packets (0x13) plen 5
    handle 12 packets 2

This patch moves sending mgmt_connected from hci_acldata_packet() to
l2cap_connect_req() since this code is to handle the scenario remote
device sends l2cap connect req too fast

Signed-off-by: Jaganath Kanakkassery &lt;jaganath.k@samsung.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()</title>
<updated>2013-01-09T19:39:05+00:00</updated>
<author>
<name>Anderson Lizardo</name>
<email>anderson.lizardo@openbossa.org</email>
</author>
<published>2013-01-06T22:28:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0a9ab9bdb3e891762553f667066190c1d22ad62b'/>
<id>0a9ab9bdb3e891762553f667066190c1d22ad62b</id>
<content type='text'>
The length parameter should be sizeof(req-&gt;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-&gt;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.)

Cc: stable@vger.kernel.org
Signed-off-by: Anderson Lizardo &lt;anderson.lizardo@openbossa.org&gt;
Acked-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The length parameter should be sizeof(req-&gt;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-&gt;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.)

Cc: stable@vger.kernel.org
Signed-off-by: Anderson Lizardo &lt;anderson.lizardo@openbossa.org&gt;
Acked-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix sending HCI commands after reset</title>
<updated>2013-01-09T19:05:14+00:00</updated>
<author>
<name>Szymon Janc</name>
<email>szymon.janc@tieto.com</email>
</author>
<published>2012-12-11T07:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dbccd791a3fbbdac12c33834b73beff3984988e9'/>
<id>dbccd791a3fbbdac12c33834b73beff3984988e9</id>
<content type='text'>
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.

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

Signed-off-by: Szymon Janc &lt;szymon.janc@tieto.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

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

Signed-off-by: Szymon Janc &lt;szymon.janc@tieto.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Gustavo Padovan &lt;gustavo.padovan@collabora.co.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
