linux-stable.git/net/tipc/socket.c, branch linux-2.6.32.y

net: rework recvmsg handler msg_name and msg_namelen logic

2014-05-19T05:54:00+00:00

CVE-2013-7266

BugLink: http://bugs.launchpad.net/bugs/1267081

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 
(back ported from commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c)
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Acked-by: Stefan Bader 
Signed-off-by: Tim Gardner 
Signed-off-by: Willy Tarreau

tipc: fix info leaks via msg_name in recv_msg/recv_stream

2013-06-10T09:43:46+00:00

commit 60085c3d009b0df252547adb336d1ccca5ce52ec upstream.

The code in set_orig_addr() does not initialize all of the members of
struct sockaddr_tipc when filling the sockaddr info -- namely the union
is only partly filled. This will make recv_msg() and recv_stream() --
the only users of this function -- leak kernel stack memory as the
msg_name member is a local variable in net/socket.c.

Additionally to that both recv_msg() and recv_stream() fail to update
the msg_namelen member to 0 while otherwise returning with 0, i.e.
"success". This is the case for, e.g., non-blocking sockets. This will
lead to a 128 byte kernel stack leak in net/socket.c.

Fix the first issue by initializing the memory of the union with
memset(0). Fix the second one by setting msg_namelen to 0 early as it
will be updated later if we're going to fill the msg_name member.

Cc: Jon Maloy 
Cc: Allan Stephens 
Signed-off-by: Mathias Krause 
Signed-off-by: David S. Miller 
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau

net: tipc: fix information leak to userland

2011-04-14T23:53:50+00:00

commit 88f8a5e3e7defccd3925cabb1ee4d3994e5cdb52 upstream.

Structure sockaddr_tipc is copied to userland with padding bytes after
"id" field in union field "name" unitialized.  It leads to leaking of
contents of kernel stack memory.  We have to initialize them to zero.

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: David S. Miller 
Cc: Moritz Muehlenhoff 
Signed-off-by: Greg Kroah-Hartman

net: Make setsockopt() optlen be unsigned.

2009-09-30T23:12:20+00:00

This provides safety against negative optlen at the type
level instead of depending upon (sometimes non-trivial)
checks against this sprinkled all over the the place, in
each and every implementation.

Based upon work done by Arjan van de Ven and feedback
from Linus Torvalds.

Signed-off-by: David S. Miller

tipc: Add socket options to get number of queued messages

2009-07-06T02:16:11+00:00

This patch allows a TIPC application to determine the number of messages
currently waiting in a socket's receive queue (TIPC_SOCK_RECVQ_DEPTH) or
in all TIPC socket receive queues (TIPC_NODE_RECVQ_DEPTH).

Signed-off-by: Oscar Medina 
Signed-off-by: Allan Stephens 
Signed-off-by: David S. Miller

tipc: Fix race condition that could cause accept() to fail

2008-07-15T05:43:32+00:00

This patch ensurs that accept() returns successfully even when
the newly created socket is immediately disconnected by its peer.
Previously, accept() would fail if it was unable to pass back
the optional address info for the socket's peer before the
socket became disconnected; TIPC now allows accept() to gather
peer address information after disconnection.  As a bonus, the
revised code accesses the socket's port more efficiently, without
the overhead incurred by a reference table lookup.

Signed-off-by: Allan Stephens 
Signed-off-by: David S. Miller

tipc: Optimize pointer dereferencing when receiving stream data

2008-07-15T05:42:51+00:00

This patch eliminates an unnecessary pointer dereference when
accessing a stream-based socket's receive queue.

Signed-off-by: Allan Stephens 
Signed-off-by: David S. Miller

tipc: Remove unneeded parameter to tipc_createport_raw()

2008-07-15T05:42:19+00:00

This patch eliminates an unneeded parameter when creating a low-level
TIPC port object.  Instead of returning both the pointer to the port
structure and the port's reference ID, it now returns only the pointer
since the port structure contains the reference ID as one of its fields.

Signed-off-by: Allan Stephens 
Signed-off-by: David S. Miller

tipc: Fix race condition when creating socket or native port

2008-05-12T22:42:28+00:00

This patch eliminates the (very remote) chance of a crash resulting
from a partially initialized socket or native port unexpectedly
receiving a message.  Now, during the creation of a socket or native
port, the underlying generic port's lock is not released until all
initialization required to handle incoming messages has been done.

Signed-off-by: Allan Stephens 
Signed-off-by: David S. Miller

net: Fix wrong interpretation of some copy_to_user() results.

2008-04-25T08:49:48+00:00

I found some places, that erroneously return the value obtained from
the copy_to_user() call: if some amount of bytes were not able to get
to the user (this is what this one returns) the proper behavior is to
return the -EFAULT error, not that number itself.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: David S. Miller