linux-stable.git/net/bluetooth/af_bluetooth.c, branch linux-3.4.y

net: rework recvmsg handler msg_name and msg_namelen logic

2013-12-08T15:29:41+00:00

[ 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 possible info leak in bt_sock_recvmsg()

2013-05-01T16:41:04+00:00

[ 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

Bluetooth: notify userspace of security level change

2012-05-14T17:51:25+00:00

It fixes L2CAP socket based security level elevation during a
connection. The HID profile needs this (for keyboards) and it is the only
way to achieve the security level elevation when using the management
interface to talk to the kernel (hence the management enabling patch
being the one that exposes this issue).

It enables the userspace a security level change when the socket is
already connected and create a way to notify the socket the result of the
request. At the moment of the request the socket is made non writable, if
the request fails the connections closes, otherwise the socket is made
writable again, POLL_OUT is emmited.

Signed-off-by: Gustavo Padovan 
Acked-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Signed-off-by: John W. Linville

Bluetooth: silence lockdep warning

2012-02-15T11:09:26+00:00

Since bluetooth uses multiple protocols types, to avoid lockdep
warnings, we need to use different lockdep classes (one for each
protocol type).

This is already done in bt_sock_create but it misses a couple of cases
when new connections are created. This patch corrects that to fix the
following warning:

<4>[ 1864.732366] =======================================================
<4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
<4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
<4>[ 1864.733883] -------------------------------------------------------
<4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
<4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.735541]
<4>[ 1864.735549] but task is already holding lock:
<4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [] lock_sock+0xa/0xc
<4>[ 1864.736732]
<4>[ 1864.736740] which lock already depends on the new lock.
<4>[ 1864.736750]
<4>[ 1864.737428]
<4>[ 1864.737437] the existing dependency chain (in reverse order) is:
<4>[ 1864.738016]
<4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
<4>[ 1864.738549]        [] lock_acquire+0x104/0x140
<4>[ 1864.738977]        [] lock_sock_nested+0x58/0x68
<4>[ 1864.739411]        [] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858]        [] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279]        [] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687]        [] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106]        [] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542]        [] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959]        [] rfcomm_run+0x441/0xb52
<4>[ 1864.742365]        [] kthread+0x63/0x68
<4>[ 1864.742742]        [] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667]        [] __lock_acquire+0x988/0xc00
<4>[ 1864.744100]        [] lock_acquire+0x104/0x140
<4>[ 1864.744519]        [] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975]        [] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412]        [] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842]        [] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288]        [] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737]        [] sys_socketcall+0x1db/0x422
<4>[ 1864.747165]        [] syscall_call+0x7/0xb

Signed-off-by: Octavian Purdila 
Acked-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Remove *_bh from socket list lock.

2012-01-03T00:20:24+00:00

We don't need it anymore.

Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: fix bt_accept_dequeue() to work in process context

2011-12-22T16:02:08+00:00

No local_bh_disable is needed there once we run everything in process
context. The same goes for the replacement of bh_lock_sock() by
lock_sock().

Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Handle fragmented skbs in bt_sock_stream_recvmsg()

2011-09-27T21:16:07+00:00

ERTM reassembly will be more efficient when skbs are linked together
rather than copying every incoming data byte. The existing stream recv
function assumes skbs are linear, so it needs to know how to handle
fragments before reassembly is changed.

bt_sock_recvmsg() already handles fragmented skbs.

Signed-off-by: Mat Martineau 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix lost wakeups waiting for sock state change

2011-08-11T22:50:26+00:00

Fix race conditions which can cause lost wakeups while waiting
for sock state to change.

Signed-off-by: Peter Hurley 
Signed-off-by: Gustavo F. Padovan

Bluetooth: remove unnecessary call to hci_sock_cleanup

2011-02-26T01:36:58+00:00

hci_sock_cleanup is already called after the sock_err label.
It appears that we can drop this call.

Signed-off-by: Anand Gadiyar 
Signed-off-by: Gustavo F. Padovan

Bluetooth: fix checkpatch errors in af_bluetooth.c

2011-02-17T22:24:05+00:00

Signed-off-by: Gustavo F. Padovan