linux-stable.git/net/tipc, branch linux-3.16.y

tipc: set sysctl_tipc_rmem and named_timeout right range

2019-08-13T11:39:11+00:00

commit 4bcd4ec1017205644a2697bccbc3b5143f522f5f upstream.

We find that sysctl_tipc_rmem and named_timeout do not have the right minimum
setting. sysctl_tipc_rmem should be larger than zero, like sysctl_tcp_rmem.
And named_timeout as a timeout setting should be not less than zero.

Fixes: cc79dd1ba9c10 ("tipc: change socket buffer overflow control to respect sk_rcvbuf")
Fixes: a5325ae5b8bff ("tipc: add name distributor resiliency queue")
Signed-off-by: Jie Liu 
Reported-by: Qiang Ning 
Reviewed-by: Zhiqiang Liu 
Reviewed-by: Miaohe Lin 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16: only the tipc_rmem sysctl exists here]
Signed-off-by: Ben Hutchings

tipc: check minimum bearer MTU

2017-02-23T03:54:42+00:00

commit 3de81b758853f0b29c61e246679d20b513c4cfec upstream.

Qian Zhang (张谦) reported a potential socket buffer overflow in
tipc_msg_build() which is also known as CVE-2016-8632: due to
insufficient checks, a buffer overflow can occur if MTU is too short for
even tipc headers. As anyone can set device MTU in a user/net namespace,
this issue can be abused by a regular user.

As agreed in the discussion on Ben Hutchings' original patch, we should
check the MTU at the moment a bearer is attached rather than for each
processed packet. We also need to repeat the check when bearer MTU is
adjusted to new device MTU. UDP case also needs a check to avoid
overflow when calculating bearer MTU.

Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
Signed-off-by: Michal Kubecek 
Reported-by: Qian Zhang (张谦) 
Acked-by: Ying Xue 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.16:
 - Adjust context
 - Duplicate macro definitions in bearer.h to avoid mutual inclusion
 - NETDEV_DOWN and NETDEV_CHANGEMTU cases in net notifier were combined
 - Drop changes in udp_media.c]
Signed-off-by: Ben Hutchings

tipc: fix an infoleak in tipc_nl_compat_link_dump

2016-08-22T21:38:28+00:00

commit 5d2be1422e02ccd697ccfcd45c85b4a26e6178e2 upstream.

link_info.str is a char array of size 60. Memory after the NULL
byte is not initialized. Sending the whole object out can cause
a leak.

Signed-off-by: Kangjie Lu 
Signed-off-by: David S. Miller 
[carnil: Backported to 3.16 (same as bwh did for 3.2): the unpadded strcpy() is
in tipc_node_get_links() and no nlattr is involved, so use strncpy()]
Signed-off-by: Ben Hutchings

net/tipc: initialize security state for new connection socket

2015-08-27T12:31:56+00:00

commit fdd75ea8df370f206a8163786e7470c1277a5064 upstream.

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 
Signed-off-by: Luis Henriques

tipc: fix message importance range check

2014-10-15T10:05:27+00:00

[ Upstream commit ac32c7f705692b92fe12dcbe88fe87136fdfff6f ]

Commit 3b4f302d8578 ("tipc: eliminate
redundant locking") introduced a bug by removing the sanity check
for message importance, allowing programs to assign any value to
the msg_user field. This will mess up the packet reception logic
and may cause random link resets.

Signed-off-by: Erik Hugne 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

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

2014-07-11T22:02:10+00:00

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

tipc: fix bug in multicast/broadcast message reassembly

2014-07-08T22:55:09+00:00

Since commit 37e22164a8a3c39bdad45aa463b1e69a1fdf4110 ("tipc: rename and
move message reassembly function") reassembly of long broadcast messages
has been broken. This is because we test for a non-NULL return value
of the *buf parameter as criteria for succesful reassembly. However, this
parameter is left defined even after reception of the first fragment,
when reassebly is still incomplete. This leads to a kernel crash as soon
as a the first fragment of a long broadcast message is received.

We fix this with this commit, by implementing a stricter behavior of the
function and its return values.

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

Signed-off-by: Jon Maloy 
Acked-by: Ying Xue 
Signed-off-by: David S. Miller

net: add __pskb_copy_fclone and pskb_copy_for_clone

2014-06-11T22:38:02+00:00

There are several instances where a pskb_copy or __pskb_copy is
immediately followed by an skb_clone.

Add a couple of new functions to allow the copy skb to be allocated
from the fclone cache and thus speed up subsequent skb_clone calls.

Cc: Alexander Smirnov 
Cc: Dmitry Eremin-Solenikov 
Cc: Marek Lindner 
Cc: Simon Wunderlich 
Cc: Antonio Quartulli 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: Arvid Brodin 
Cc: Patrick McHardy 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Lauro Ramos Venancio 
Cc: Aloisio Almeida Jr 
Cc: Samuel Ortiz 
Cc: Jon Maloy 
Cc: Allan Stephens 
Cc: Andrew Hendry 
Cc: Eric Dumazet 
Reviewed-by: Christoph Paasch 
Signed-off-by: Octavian Purdila 
Signed-off-by: David S. Miller

tipc: fix potential bug in function tipc_backlog_rcv

2014-06-11T22:01:30+00:00

In commit 4f4482dcd9a0606a30541ff165ddaca64748299b ("tipc: compensate
for double accounting in socket rcv buffer") we access 'truesize' of
a received buffer after it might have been released by the function
filter_rcv().

In this commit we correct this by reading the value of 'truesize' to
the stack before delivering the buffer to filter_rcv().

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

tipc: Don't reset the timeout when restarting

2014-05-24T18:11:41+00:00

As it may then take longer than what the user specified using
setsockopt(SO_RCVTIMEO).

Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Jon Maloy 
Signed-off-by: David S. Miller