linux/net/bluetooth, branch v3.4.96

Bluetooth: Fix invalid length check in l2cap_information_rsp()

2014-06-11T19:04:13Z

commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 upstream. The length check is invalid since the length varies with type of info response. This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888 Because of this, l2cap info rsp is not handled and command reject is sent. > ACL data: handle 11 flags 0x02 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00b8 Enhanced Retransmission mode Streaming mode FCS Option Fixed Channels < ACL data: handle 11 flags 0x00 dlen 10 L2CAP(s): Command rej: reason 0 Command not understood Cc: stable@vger.kernel.org Signed-off-by: Jaganath Kanakkassery Signed-off-by: Chan-Yeol Park Acked-by: Johan Hedberg Signed-off-by: Gustavo Padovan Cc: Jianguo Wu Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix missing length checks for L2CAP signalling PDUs

2014-06-11T19:04:13Z

commit cb3b3152b2f5939d67005cff841a1ca748b19888 upstream. There has been code in place to check that the L2CAP length header matches the amount of data received, but many PDU handlers have not been checking that the data received actually matches that expected by the specific PDU. This patch adds passing the length header to the specific handler functions and ensures that those functions fail cleanly in the case of an incorrect amount of data. Signed-off-by: Johan Hedberg Signed-off-by: Gustavo Padovan Signed-off-by: John W. Linville [bwh: Backported to 3.2: - Adjust context - Move uses of *req below the new check in l2cap_connect_req] Signed-off-by: Ben Hutchings [wujg: Backported to 3.4: - Adjust context - Adjust l2cap_create_channel_rsp()'s parameters] Signed-off-by: Jianguo Wu Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix removing Long Term Key

2014-04-27T00:13:19Z

commit 5981a8821b774ada0be512fd9bad7c241e17657e upstream. This patch fixes authentication failure on LE link re-connection when BlueZ acts as slave (peripheral). LTK is removed from the internal list after its first use causing PIN or Key missing reply when re-connecting the link. The LE Long Term Key Request event indicates that the master is attempting to encrypt or re-encrypt the link. Pre-condition: BlueZ host paired and running as slave. How to reproduce(master): 1) Establish an ACL LE encrypted link 2) Disconnect the link 3) Try to re-establish the ACL LE encrypted link (fails) > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 64 Role: Slave (0x01) ... @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000 > HCI Event: LE Meta Event (0x3e) plen 13 LE Long Term Key Request (0x05) Handle: 64 Random number: 875be18439d9aa37 Encryption diversifier: 0x76ed < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18 Handle: 64 Long term key: 2aa531db2fce9f00a0569c7d23d17409 > HCI Event: Command Complete (0x0e) plen 6 LE Long Term Key Request Reply (0x08|0x001a) ncmd 1 Status: Success (0x00) Handle: 64 > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 64 Encryption: Enabled with AES-CCM (0x01) ... @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3 < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 Advertising: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertise Enable (0x08|0x000a) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 64 Role: Slave (0x01) ... @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000 > HCI Event: LE Meta Event (0x3e) plen 13 LE Long Term Key Request (0x05) Handle: 64 Random number: 875be18439d9aa37 Encryption diversifier: 0x76ed < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2 Handle: 64 > HCI Event: Command Complete (0x0e) plen 6 LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1 Status: Success (0x00) Handle: 64 > HCI Event: Disconnect Complete (0x05) plen 4 Status: Success (0x00) Handle: 64 Reason: Authentication Failure (0x05) @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0 Signed-off-by: Claudio Takahasi Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman

net: rework recvmsg handler msg_name and msg_namelen logic

2013-12-08T15:29:41Z

[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ] This patch now always passes msg->msg_namelen as 0. recvmsg handlers must set msg_namelen to the proper size <= sizeof(struct sockaddr_storage) to return msg_name to the user. This prevents numerous uninitialized memory leaks we had in the recvmsg handlers and makes it harder for new code to accidentally leak uninitialized memory. Optimize for the case recvfrom is called with NULL as address. We don't need to copy the address at all, so set it to NULL before invoking the recvmsg handler. We can do so, because all the recvmsg handlers must cope with the case a plain read() is called on them. read() also sets msg_name to NULL. Also document these changes in include/linux/net.h as suggested by David Miller. Changes since RFC: Set msg->msg_name = NULL if user specified a NULL in msg_name but had a non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't affect sendto as it would bail out earlier while trying to copy-in the address. It also more naturally reflects the logic by the callers of verify_iovec. With this change in place I could remove " if (!uaddr || msg_sys->msg_namelen == 0) msg->msg_name = NULL ". This change does not alter the user visible error logic as we ignore msg_namelen as long as msg_name is NULL. Also remove two unnecessary curly brackets in ___sys_recvmsg and change comments to netdev style. Cc: David Miller Suggested-by: Eric Dumazet Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix encryption key size for peripheral role

2013-10-13T22:42:48Z

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-13T22:42:48Z

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

Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

2013-07-03T17:59:00Z

commit 300b962e5244a1ea010df7e88595faa0085b461d upstream. If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus controller, memory corruption happens due to a memcpy() call with negative length. Fix this crash on either incoming or outgoing connections with a MTU smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE: [ 46.885433] BUG: unable to handle kernel paging request at f56ad000 [ 46.888037] IP: [] memcpy+0x1d/0x40 [ 46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060 [ 46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC [ 46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common [ 46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12 [ 46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 46.888037] Workqueue: hci0 hci_rx_work [bluetooth] [ 46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000 [ 46.888037] EIP: 0060:[] EFLAGS: 00010212 CPU: 0 [ 46.888037] EIP is at memcpy+0x1d/0x40 [ 46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2 [ 46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c [ 46.888037] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0 [ 46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 46.888037] DR6: ffff0ff0 DR7: 00000400 [ 46.888037] Stack: [ 46.888037] fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000 [ 46.888037] f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560 [ 46.888037] f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2 [ 46.888037] Call Trace: [ 46.888037] [] l2cap_send_cmd+0x1cc/0x230 [bluetooth] [ 46.888037] [] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth] [ 46.888037] [] l2cap_connect+0x3f7/0x540 [bluetooth] [ 46.888037] [] ? trace_hardirqs_off+0xb/0x10 [ 46.888037] [] ? mark_held_locks+0x68/0x110 [ 46.888037] [] ? mutex_lock_nested+0x280/0x360 [ 46.888037] [] ? __mutex_unlock_slowpath+0xa9/0x150 [ 46.888037] [] ? trace_hardirqs_on_caller+0xec/0x1b0 [ 46.888037] [] ? mutex_lock_nested+0x268/0x360 [ 46.888037] [] ? trace_hardirqs_on+0xb/0x10 [ 46.888037] [] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth] [ 46.888037] [] ? mark_held_locks+0x68/0x110 [ 46.888037] [] ? __mutex_unlock_slowpath+0xa9/0x150 [ 46.888037] [] ? trace_hardirqs_on_caller+0xec/0x1b0 [ 46.888037] [] l2cap_recv_acldata+0x2a1/0x320 [bluetooth] [ 46.888037] [] hci_rx_work+0x518/0x810 [bluetooth] [ 46.888037] [] ? hci_rx_work+0x132/0x810 [bluetooth] [ 46.888037] [] process_one_work+0x1a9/0x600 [ 46.888037] [] ? process_one_work+0x12b/0x600 [ 46.888037] [] ? worker_thread+0x19e/0x320 [ 46.888037] [] ? worker_thread+0x19e/0x320 [ 46.888037] [] worker_thread+0xf7/0x320 [ 46.888037] [] ? rescuer_thread+0x290/0x290 [ 46.888037] [] kthread+0xa8/0xb0 [ 46.888037] [] ret_from_kernel_thread+0x1b/0x28 [ 46.888037] [] ? flush_kthread_worker+0x120/0x120 [ 46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89 [ 46.888037] EIP: [] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c [ 46.888037] CR2: 00000000f56ad000 [ 46.888037] ---[ end trace 0217c1f4d78714a9 ]--- Signed-off-by: Anderson Lizardo Signed-off-by: Gustavo Padovan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix mgmt handling of power on failures

2013-06-20T18:58:44Z

commit 96570ffcca0b872dc8626e97569d2697f374d868 upstream. If hci_dev_open fails we need to ensure that the corresponding mgmt_set_powered command gets an appropriate response. This patch fixes the missing response by adding a new mgmt_set_powered_failed function that's used to indicate a power on failure to mgmt. Since a situation with the device being rfkilled may require special handling in user space the patch uses a new dedicated mgmt status code for this. Signed-off-by: Johan Hedberg Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

2013-05-01T16:41:04Z

[ 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 Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Bluetooth: fix possible info leak in bt_sock_recvmsg()

2013-05-01T16:41:04Z

[ 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 Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman