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

tipc: don't use memcpy to copy from user space

2014-08-26T12:12:22+00:00

commit 5c0a0fc81f4dc786b42c4fc9c7c72ba635406ab5 upstream.

tipc_msg_build() calls skb_copy_to_linear_data_offset() to copy data
from user space to kernel space. However, the latter function does
in its turn call memcpy() to perform the actual copying. This poses
an obvious security and robustness risk, since memcpy() never makes
any validity check on the pointer it is copying from.

To correct this, we the replace the offending function call with
a call to memcpy_fromiovecend(), which uses copy_from_user() to
perform the copying.

Signed-off-by: Ying Xue 
Reviewed-by: Paul Gortmaker 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: clear 'next'-pointer of message fragments before reassembly

2014-07-29T15:01:38+00:00

[ Upstream commit 999417549c16dd0e3a382aa9f6ae61688db03181 ]

If the 'next' pointer of the last fragment buffer in a message is not
zeroed before reassembly, we risk ending up with a corrupt message,
since the reassembly function itself isn't doing this.

Currently, when a buffer is retrieved from the deferred queue of the
broadcast link, the next pointer is not cleared, with the result as
described above.

This commit corrects this, and thereby fixes a bug that may occur when
long broadcast messages are transmitted across dual interfaces. The bug
has been present since 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
message reassembly using fragment chain")

This commit should be applied to both net and net-next.

Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: fix memory leak of publications

2014-06-27T08:25:13+00:00

commit 1621b94d2a655c8548ddbdfc8ccf907a5bbdc860 upstream.

Commit 1bb8dce57f4d15233688c68990852a10eb1cd79f ("tipc: fix memory
leak during module removal") introduced a memory leak issue: when
name table is stopped, it's forgotten that publication instances are
freed properly. Additionally the useless "continue" statement in
tipc_nametbl_stop() is removed as well.

Reported-by: Jason 
Signed-off-by: Ying Xue 
Acked-by: Erik Hugne 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

net: Use netlink_ns_capable to verify the permisions of netlink messages

2014-06-23T08:27:57+00:00

[ Upstream commit 90f62cf30a78721641e08737bda787552428061e ]

It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.

To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.

Reported-by: Andy Lutomirski 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: fix spinlock recursion bug for failed subscriptions

2014-04-18T09:07:11+00:00

[ Upstream commit a5d0e7c037119484a7006b883618bfa87996cb41 ]

If a topology event subscription fails for any reason, such as out
of memory, max number reached or because we received an invalid
request the correct behavior is to terminate the subscribers
connection to the topology server. This is currently broken and
produces the following oops:

[27.953662] tipc: Subscription rejected, illegal request
[27.955329] BUG: spinlock recursion on CPU#1, kworker/u4:0/6
[27.957066]  lock: 0xffff88003c67f408, .magic: dead4ead, .owner: kworker/u4:0/6, .owner_cpu: 1
[27.958054] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.0-rc6+ #5
[27.960230] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[27.960874] Workqueue: tipc_rcv tipc_recv_work [tipc]
[27.961430]  ffff88003c67f408 ffff88003de27c18 ffffffff815c0207 ffff88003de1c050
[27.962292]  ffff88003de27c38 ffffffff815beec5 ffff88003c67f408 ffffffff817f0a8a
[27.963152]  ffff88003de27c58 ffffffff815beeeb ffff88003c67f408 ffffffffa0013520
[27.964023] Call Trace:
[27.964292]  [] dump_stack+0x45/0x56
[27.964874]  [] spin_dump+0x8c/0x91
[27.965420]  [] spin_bug+0x21/0x26
[27.965995]  [] do_raw_spin_lock+0x116/0x140
[27.966631]  [] _raw_spin_lock_bh+0x15/0x20
[27.967256]  [] subscr_conn_shutdown_event+0x20/0xa0 [tipc]
[27.968051]  [] tipc_close_conn+0xa4/0xb0 [tipc]
[27.968722]  [] tipc_conn_terminate+0x1a/0x30 [tipc]
[27.969436]  [] subscr_conn_msg_event+0x1f2/0x2f0 [tipc]
[27.970209]  [] tipc_receive_from_sock+0x90/0xf0 [tipc]
[27.970972]  [] tipc_recv_work+0x29/0x50 [tipc]
[27.971633]  [] process_one_work+0x165/0x3e0
[27.972267]  [] worker_thread+0x119/0x3a0
[27.972896]  [] ? manage_workers.isra.25+0x2a0/0x2a0
[27.973622]  [] kthread+0xdf/0x100
[27.974168]  [] ? kthread_create_on_node+0x1a0/0x1a0
[27.974893]  [] ret_from_fork+0x7c/0xb0
[27.975466]  [] ? kthread_create_on_node+0x1a0/0x1a0

The recursion occurs when subscr_terminate tries to grab the
subscriber lock, which is already taken by subscr_conn_msg_event.
We fix this by checking if the request to establish a new
subscription was successful, and if not we initiate termination of
the subscriber after we have released the subscriber lock.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: don't log disabled tasklet handler errors

2014-04-18T09:06:57+00:00

[ Upstream commit 2892505ea170094f982516bb38105eac45f274b1 ]

Failure to schedule a TIPC tasklet with tipc_k_signal because the
tasklet handler is disabled is not an error. It means TIPC is
currently in the process of shutting down. We remove the error
logging in this case.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: fix memory leak during module removal

2014-04-18T09:06:56+00:00

[ Upstream commit 1bb8dce57f4d15233688c68990852a10eb1cd79f ]

When the TIPC module is removed, the tasklet handler is disabled
before all other subsystems. This will cause lingering publications
in the name table because the node_down tasklets responsible to
clean up publications from an unreachable node will never run.
When the name table is shut down, these publications are detected
and an error message is logged:
tipc: nametbl_stop(): orphaned hash chain detected
This is actually a memory leak, introduced with commit
993b858e37b3120ee76d9957a901cca22312ffaa ("tipc: correct the order
of stopping services at rmmod")

Instead of just logging an error and leaking memory, we free
the orphaned entries during nametable shutdown.

Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: drop subscriber connection id invalidation

2014-04-18T09:06:56+00:00

[ Upstream commit edcc0511b5ee7235282a688cd604e3ae7f9e1fc9 ]

When a topology server subscriber is disconnected, the associated
connection id is set to zero. A check vs zero is then done in the
subscription timeout function to see if the subscriber have been
shut down. This is unnecessary, because all subscription timers
will be cancelled when a subscriber terminates. Setting the
connection id to zero is actually harmful because id zero is the
identity of the topology server listening socket, and can cause a
race that leads to this socket being closed instead.

Signed-off-by: Erik Hugne 
Acked-by: Ying Xue 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: fix connection refcount leak

2014-04-18T09:06:55+00:00

[ Upstream commit 4652edb70e8a7eebbe47fa931940f65522c36e8f ]

When tipc_conn_sendmsg() calls tipc_conn_lookup() to query a
connection instance, its reference count value is increased if
it's found. But subsequently if it's found that the connection is
closed, the work of sending message is not queued into its server
send workqueue, and the connection reference count is not decreased.
This will cause a reference count leak. To reproduce this problem,
an application would need to open and closes topology server
connections with high intensity.

We fix this by immediately decrementing the connection reference
count if a send fails due to the connection being closed.

Signed-off-by: Ying Xue 
Acked-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

tipc: allow connection shutdown callback to be invoked in advance

2014-04-18T09:06:54+00:00

[ Upstream commit 6d4ebeb4df0176b1973875840a9f7e91394c0685 ]

Currently connection shutdown callback function is called when
connection instance is released in tipc_conn_kref_release(), and
receiving packets and sending packets are running in different
threads. Even if connection is closed by the thread of receiving
packets, its shutdown callback may not be called immediately as
the connection reference count is non-zero at that moment. So,
although the connection is shut down by the thread of receiving
packets, the thread of sending packets doesn't know it. Before
its shutdown callback is invoked to tell the sending thread its
connection has been closed, the sending thread may deliver
messages by tipc_conn_sendmsg(), this is why the following error
information appears:

"Sending subscription event failed, no memory"

To eliminate it, allow connection shutdown callback function to
be called before connection id is removed in tipc_close_conn(),
which makes the sending thread know the truth in time that its
socket is closed so that it doesn't send message to it. We also
remove the "Sending XXX failed..." error reporting for topology
and config services.

Signed-off-by: Ying Xue 
Signed-off-by: Erik Hugne 
Reviewed-by: Jon Maloy 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby