linux-stable.git/net/sctp, branch linux-4.7.y

sctp: fix overrun in sctp_diag_dump_one()

2016-09-24T08:09:25+00:00

[ Upstream commit 232cb53a45965f8789fbf0a9a1962f8c67ab1a3c ]

The function sctp_diag_dump_one() currently performs a memcpy()
of 64 bytes from a 16 byte field into another 16 byte field. Fix
by using correct size, use sizeof to obtain correct size instead
of using a hard-coded constant.

Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
Signed-off-by: Lance Richardson 
Reviewed-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sctp: always initialise sctp_ht_iter::start_fail

2016-09-24T08:09:24+00:00

[ Upstream commit 54236ab09e9696a27baaae693c288920a26e8588 ]

sctp_transport_seq_start() does not currently clear iter->start_fail on
success, but relies on it being zero when it is allocated (by
seq_open_net()).

This can be a problem in the following sequence:

    open() // allocates iter (and implicitly sets iter->start_fail = 0)
    read()
     - iter->start() // fails and sets iter->start_fail = 1
     - iter->stop() // doesn't call sctp_transport_walk_stop() (correct)
    read() again
     - iter->start() // succeeds, but doesn't change iter->start_fail
     - iter->stop() // doesn't call sctp_transport_walk_stop() (wrong)

We should initialize sctp_ht_iter::start_fail to zero if ->start()
succeeds, otherwise it's possible that we leave an old value of 1 there,
which will cause ->stop() to not call sctp_transport_walk_stop(), which
causes all sorts of problems like not calling rcu_read_unlock() (and
preempt_enable()), eventually leading to more warnings like this:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 16551, name: trinity-c2
    Preemption disabled at:[] rhashtable_walk_start+0x46/0x150

     [] preempt_count_add+0x1fb/0x280
     [] _raw_spin_lock+0x12/0x40
     [] rhashtable_walk_start+0x46/0x150
     [] sctp_transport_walk_start+0x2f/0x60
     [] sctp_transport_seq_start+0x4d/0x150
     [] traverse+0x170/0x850
     [] seq_read+0x7cc/0x1180
     [] proc_reg_read+0xbc/0x180
     [] do_loop_readv_writev+0x134/0x210
     [] do_readv_writev+0x565/0x660
     [] vfs_readv+0x67/0xa0
     [] do_preadv+0x126/0x170
     [] SyS_preadv+0xc/0x10
     [] do_syscall_64+0x19c/0x410
     [] return_from_SYSCALL_64+0x0/0x6a
     [] 0xffffffffffffffff

Notice that this is a subtly different stacktrace from the one in commit
5fc382d875 ("net/sctp: terminate rhashtable walk correctly").

Cc: Xin Long 
Cc: Herbert Xu 
Cc: Eric W. Biederman 
Cc: Marcelo Ricardo Leitner 
Signed-off-by: Vegard Nossum 
Acked-By: Neil Horman 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/sctp: terminate rhashtable walk correctly

2016-08-16T07:34:58+00:00

[ Upstream commit 5fc382d87517707ad77ea4c9c12e2a3fde2c838a ]

I was seeing a lot of these:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 14971, name: trinity-c2
    Preemption disabled at:[] rhashtable_walk_start+0x46/0x150

     [] preempt_count_add+0x1fb/0x280
     [] _raw_spin_lock+0x12/0x40
     [] console_unlock+0x2f7/0x930
     [] vprintk_emit+0x2fb/0x520
     [] vprintk_default+0x1a/0x20
     [] printk+0x94/0xb0
     [] print_stack_trace+0xe0/0x170
     [] ___might_sleep+0x3be/0x460
     [] __might_sleep+0x90/0x1a0
     [] kmem_cache_alloc+0x153/0x1e0
     [] rhashtable_walk_init+0xfe/0x2d0
     [] sctp_transport_walk_start+0x1e/0x60
     [] sctp_transport_seq_start+0x4d/0x150
     [] seq_read+0x27b/0x1180
     [] proc_reg_read+0xbc/0x180
     [] __vfs_read+0xdb/0x610
     [] vfs_read+0xea/0x2d0
     [] SyS_pread64+0x11b/0x150
     [] do_syscall_64+0x19c/0x410
     [] return_from_SYSCALL_64+0x0/0x6a
     [] 0xffffffffffffffff

Apparently we always need to call rhashtable_walk_stop(), even when
rhashtable_walk_start() fails:

 * rhashtable_walk_start - Start a hash table walk
 * @iter:       Hash table iterator
 *
 * Start a hash table walk.  Note that we take the RCU lock in all
 * cases including when we return an error.  So you must always call
 * rhashtable_walk_stop to clean up.

otherwise we never call rcu_read_unlock() and we get the splat above.

Fixes: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: f2dba9c6 ("rhashtable: Introduce rhashtable_walk_*")
Cc: Xin Long 
Cc: Herbert Xu 
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: fix BH handling on socket backlog

2016-08-16T07:34:58+00:00

[ Upstream commit eefc1b1d105ee4d2ce907833ce675f1e9599b5e3 ]

Now that the backlog processing is called with BH enabled, we have to
disable BH before taking the socket lock via bh_lock_sock() otherwise
it may dead lock:

sctp_backlog_rcv()
                bh_lock_sock(sk);

                if (sock_owned_by_user(sk)) {
                        if (sk_add_backlog(sk, skb, sk->sk_rcvbuf))
                                sctp_chunk_free(chunk);
                        else
                                backloged = 1;
                } else
                        sctp_inq_push(inqueue, chunk);

                bh_unlock_sock(sk);

while sctp_inq_push() was disabling/enabling BH, but enabling BH
triggers pending softirq, which then may try to re-lock the socket in
sctp_rcv().

[  219.187215]  
[  219.187217]  [] _raw_spin_lock+0x20/0x30
[  219.187223]  [] sctp_rcv+0x48c/0xba0 [sctp]
[  219.187225]  [] ? nf_iterate+0x62/0x80
[  219.187226]  [] ip_local_deliver_finish+0x94/0x1e0
[  219.187228]  [] ip_local_deliver+0x6f/0xf0
[  219.187229]  [] ? ip_rcv_finish+0x3b0/0x3b0
[  219.187230]  [] ip_rcv_finish+0xd8/0x3b0
[  219.187232]  [] ip_rcv+0x282/0x3a0
[  219.187233]  [] ? update_curr+0x66/0x180
[  219.187235]  [] __netif_receive_skb_core+0x524/0xa90
[  219.187236]  [] ? update_cfs_shares+0x30/0xf0
[  219.187237]  [] ? __enqueue_entity+0x6c/0x70
[  219.187239]  [] ? enqueue_entity+0x204/0xdf0
[  219.187240]  [] __netif_receive_skb+0x18/0x60
[  219.187242]  [] process_backlog+0x9e/0x140
[  219.187243]  [] net_rx_action+0x22c/0x370
[  219.187245]  [] __do_softirq+0x112/0x2e7
[  219.187247]  [] do_softirq_own_stack+0x1c/0x30
[  219.187247]  
[  219.187248]  [] do_softirq.part.14+0x38/0x40
[  219.187249]  [] __local_bh_enable_ip+0x7d/0x80
[  219.187254]  [] sctp_inq_push+0x68/0x80 [sctp]
[  219.187258]  [] sctp_backlog_rcv+0x151/0x1c0 [sctp]
[  219.187260]  [] __release_sock+0x87/0xf0
[  219.187261]  [] release_sock+0x30/0xa0
[  219.187265]  [] sctp_accept+0x17d/0x210 [sctp]
[  219.187266]  [] ? prepare_to_wait_event+0xf0/0xf0
[  219.187268]  [] inet_accept+0x3c/0x130
[  219.187269]  [] SYSC_accept4+0x103/0x210
[  219.187271]  [] ? _raw_spin_unlock_bh+0x1a/0x20
[  219.187272]  [] ? release_sock+0x8c/0xa0
[  219.187276]  [] ? sctp_inet_listen+0x62/0x1b0 [sctp]
[  219.187277]  [] SyS_accept+0x10/0x20

Fixes: 860fbbc343bf ("sctp: prepare for socket backlog behavior change")
Cc: Eric Dumazet 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: load transport header after sk_filter

2016-07-19T05:46:52+00:00

Do not cache pointers into the skb linear segment across sk_filter.
The function call can trigger pskb_expand_head.

Signed-off-by: Willem de Bruijn 
Acked-by: Daniel Borkmann 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

net: diag: add missing declarations

2016-06-11T06:22:55+00:00

The functions inet_diag_msg_common_fill and inet_diag_msg_attrs_fill
seem to have been missed from the include/linux/inet_diag.h header
file. Add them to fix the following warnings:

net/ipv4/inet_diag.c:69:6: warning: symbol 'inet_diag_msg_common_fill' was not declared. Should it be static?
net/ipv4/inet_diag.c:108:5: warning: symbol 'inet_diag_msg_attrs_fill' was not declared. Should it be static?

Signed-off-by: Ben Dooks 
Signed-off-by: David S. Miller

sctp: sctp_diag should dump sctp socket type

2016-05-31T18:59:06+00:00

Now we cannot distinguish that one sk is a udp or sctp style when
we use ss to dump sctp_info. it's necessary to dump it as well.

For sctp_diag, ss support is not officially available, thus there
are no official users of this yet, so we can add this field in the
middle of sctp_info without breaking user API.

v1->v2:
  - move 'sctpi_s_type' field to the end of struct sctp_info, so
    that it won't cause incompatibility with applications already
    built.
  - add __reserved3 in sctp_info to make sure sctp_info is 8-byte
    alignment.

Signed-off-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller

sctp: fix double EPs display in sctp_diag

2016-05-26T05:14:31+00:00

We have this situation: that EP hash table, contains only the EPs
that are listening, while the transports one, has the opposite.
We have to traverse both to dump all.

But when we traverse the transports one we will also get EPs that are
in the EP hash if they are listening. In this case, the EP is dumped
twice.

We will fix it by checking if the endpoint that is in the endpoint
hash table contains any ep->asoc in there, as it means we will also
find it via transport hash, and thus we can/should skip it, depending
on the filters used, like 'ss -l'.

Still, we should NOT skip it if the user is listing only listening
endpoints, because then we are not traversing the transport hash.
so we have to check idiag_states there also.

Signed-off-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

sctp: prepare for socket backlog behavior change

2016-05-02T21:02:26+00:00

sctp_inq_push() will soon be called without BH being blocked
when generic socket code flushes the socket backlog.

It is very possible SCTP can be converted to not rely on BH,
but this needs to be done by SCTP experts.

Signed-off-by: Eric Dumazet 
Acked-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller

sctp: signal sk_data_ready earlier on data chunks reception

2016-05-02T01:06:10+00:00

Dave Miller pointed out that fb586f25300f ("sctp: delay calls to
sk_data_ready() as much as possible") may insert latency specially if
the receiving application is running on another CPU and that it would be
better if we signalled as early as possible.

This patch thus basically inverts the logic on fb586f25300f and signals
it as early as possible, similar to what we had before.

Fixes: fb586f25300f ("sctp: delay calls to sk_data_ready() as much as possible")
Reported-by: Dave Miller 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller