linux-toradex.git/net/tipc, branch v3.2.74

net/tipc: initialize security state for new connection socket

2015-10-13T02:46:12+00:00

[ Upstream commit fdd75ea8df370f206a8163786e7470c1277a5064 ]

Calling connect() with an AF_TIPC socket would trigger a series
of error messages from SELinux along the lines of:
SELinux: Invalid class 0
type=AVC msg=audit(1434126658.487:34500): avc:  denied  {  }
  for pid=292 comm="kworker/u16:5" scontext=system_u:system_r:kernel_t:s0
  tcontext=system_u:object_r:unlabeled_t:s0 tclass=
  permissive=0

This was due to a failure to initialize the security state of the new
connection sock by the tipc code, leaving it with junk in the security
class field and an unlabeled secid.  Add a call to security_sk_clone()
to inherit the security state from the parent socket.

Reported-by: Tim Shearer 
Signed-off-by: Stephen Smalley 
Acked-by: Paul Moore 
Acked-by: Ying Xue 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings

net: rework recvmsg handler msg_name and msg_namelen logic

2014-01-03T04:33:33+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: Ben Hutchings

tipc: fix lockdep warning during bearer initialization

2013-10-26T20:05:57+00:00

[ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

When the lockdep validator is enabled, it will report the below
warning when we enable a TIPC bearer:

[ INFO: possible irq lock inversion dependency detected ]
---------------------------------------------------------
Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(ptype_lock);
                                local_irq_disable();
                                lock(tipc_net_lock);
                                lock(ptype_lock);
   
   lock(tipc_net_lock);

  *** DEADLOCK ***

the shortest dependencies between 2nd lock and 1st lock:
  -> (ptype_lock){+.+...} ops: 10 {
[...]
SOFTIRQ-ON-W at:
                      [] __lock_acquire+0x528/0x13e0
                      [] lock_acquire+0x90/0x100
                      [] _raw_spin_lock+0x38/0x50
                      [] dev_add_pack+0x3a/0x60
                      [] arp_init+0x1a/0x48
                      [] inet_init+0x181/0x27e
                      [] do_one_initcall+0x34/0x170
                      [] kernel_init+0x110/0x1b2
                      [] kernel_thread_helper+0x6/0x10
[...]
   ... key      at: [] ptype_lock+0x10/0x20
   ... acquired at:
    [] lock_acquire+0x90/0x100
    [] _raw_spin_lock+0x38/0x50
    [] dev_add_pack+0x3a/0x60
    [] enable_bearer+0xf2/0x140 [tipc]
    [] tipc_enable_bearer+0x1ba/0x450 [tipc]
    [] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
    [] handle_cmd+0x42/0xd0 [tipc]
    [] genl_rcv_msg+0x232/0x280
    [] netlink_rcv_skb+0x86/0xb0
    [] genl_rcv+0x1c/0x30
    [] netlink_unicast+0x174/0x1f0
    [] netlink_sendmsg+0x1eb/0x2d0
    [] sock_aio_write+0x161/0x170
    [] do_sync_write+0xac/0xf0
    [] vfs_write+0x156/0x170
    [] sys_write+0x42/0x70
    [] sysenter_do_call+0x12/0x38
[...]
}
  -> (tipc_net_lock){+..-..} ops: 4 {
[...]
    IN-SOFTIRQ-R at:
                     [] __lock_acquire+0x64a/0x13e0
                     [] lock_acquire+0x90/0x100
                     [] _raw_read_lock_bh+0x3d/0x50
                     [] tipc_recv_msg+0x1d/0x830 [tipc]
                     [] recv_msg+0x3f/0x50 [tipc]
                     [] __netif_receive_skb+0x22a/0x590
                     [] netif_receive_skb+0x2b/0xf0
                     [] pcnet32_poll+0x292/0x780
                     [] net_rx_action+0xfa/0x1e0
                     [] __do_softirq+0xae/0x1e0
[...]
}

>From the log, we can see three different call chains between
CPU0 and CPU1:

Time 0 on CPU0:

  kernel_init()->inet_init()->dev_add_pack()

At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

Time 1 on CPU1:

  tipc_enable_bearer()->enable_bearer()->dev_add_pack()

At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
wants to take ptype_lock to register TIPC protocol handler into the
networking stack.  But the ptype_lock has been taken by dev_add_pack()
on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
busy looping.

Time 2 on CPU0:

  netif_receive_skb()->recv_msg()->tipc_recv_msg()

At time 2, an incoming TIPC packet arrives at CPU0, hence
tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
to hold tipc_net_lock.  At the moment, below scenario happens:

On CPU0, below is our sequence of taking locks:

  lock(ptype_lock)->lock(tipc_net_lock)

On CPU1, our sequence of taking locks looks like:

  lock(tipc_net_lock)->lock(ptype_lock)

Obviously deadlock may happen in this case.

But please note the deadlock possibly doesn't occur at all when the
first TIPC bearer is enabled.  Before enable_bearer() -- running on
CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
recv_msg()) is not registered successfully via dev_add_pack(), so
the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
message comes to CPU0. But when the second TIPC bearer is
registered, the deadlock can perhaps really happen.

To fix it, we will push the work of registering TIPC protocol
handler into workqueue context. After the change, both paths taking
ptype_lock are always in process contexts, thus, the deadlock should
never occur.

Signed-off-by: Ying Xue 
Signed-off-by: Jon Maloy 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

tipc: fix info leaks via msg_name in recv_msg/recv_stream

2013-05-13T14:02:41+00:00

[ Upstream commit 60085c3d009b0df252547adb336d1ccca5ce52ec ]

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 
Signed-off-by: Ben Hutchings

net: Add export.h for EXPORT_SYMBOL/THIS_MODULE to non-modules

2011-10-31T23:30:30+00:00

These files are non modular, but need to export symbols using
the macros now living in export.h -- call out the include so
that things won't break when we remove the implicit presence
of module.h from everywhere.

Signed-off-by: Paul Gortmaker

net: Fix files explicitly needing to include module.h

2011-10-31T23:30:28+00:00

With calls to modular infrastructure, these files really
needs the full module.h header.  Call it out so some of the
cleanups of implicit and unrequired includes elsewhere can be
cleaned up.

Signed-off-by: Paul Gortmaker

tipc: Remove unused link event tracking code

2011-09-18T02:55:15+00:00

Elimintes prototype link event tracking functionality that has never
been fleshed out and doesn't do anything useful at the current time.

Signed-off-by: Ying Xue 
Signed-off-by: Allan Stephens 
Signed-off-by: Paul Gortmaker

tipc: Remove callback field from subscription structure

2011-09-18T02:55:14+00:00

Eliminate the "event_cb" member from TIPC's "subscription" structure
since the function pointer it holds always points to subscr_send_event().

Signed-off-by: Ying Xue 
Signed-off-by: Allan Stephens 
Signed-off-by: Paul Gortmaker

tipc: Simplify prohibition of listen and accept for connectionless sockets

2011-09-18T02:55:12+00:00

Modifies the proto_ops structure used by TIPC DGRAM and RDM sockets
so that calls to listen() and accept() are handled by existing kernel
"unsupported operation" routines, and eliminates the related checks
in the listen and accept routines used by SEQPACKET and STREAM sockets
that are no longer needed.

Signed-off-by: Ying Xue 
Signed-off-by: Allan Stephens 
Signed-off-by: Paul Gortmaker

tipc: Add support for SO_SNDTIMEO socket option

2011-09-18T02:55:11+00:00

Adds support for the SO_SNDTIMEO socket option. (This complements the
existing support for SO_RCVTIMEO that is already present.)

Signed-off-by: Ying Xue 
Signed-off-by: Allan Stephens 
Signed-off-by: Paul Gortmaker