linux.git/net/ipv4, branch v4.4-rc4

ipv4: igmp: Allow removing groups from a removed interface

2015-12-03T17:07:05+00:00

When a multicast group is joined on a socket, a struct ip_mc_socklist
is appended to the sockets mc_list containing information about the
joined group.

If the interface is hot unplugged, this entry becomes stale. Prior to
commit 52ad353a5344f ("igmp: fix the problem when mc leave group") it
was possible to remove the stale entry by performing a
IP_DROP_MEMBERSHIP, passing either the old ifindex or ip address on
the interface. However, this fix enforces that the interface must
still exist. Thus with time, the number of stale entries grows, until
sysctl_igmp_max_memberships is reached and then it is not possible to
join and more groups.

The previous patch fixes an issue where a IP_DROP_MEMBERSHIP is
performed without specifying the interface, either by ifindex or ip
address. However here we do supply one of these. So loosen the
restriction on device existence to only apply when the interface has
not been specified. This then restores the ability to clean up the
stale entries.

Signed-off-by: Andrew Lunn 
Fixes: 52ad353a5344f "(igmp: fix the problem when mc leave group")
Signed-off-by: David S. Miller

net: rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA

2015-12-01T20:45:05+00:00

This patch is a cleanup to make following patch easier to
review.

Goal is to move SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA
from (struct socket)->flags to a (struct socket_wq)->flags
to benefit from RCU protection in sock_wake_async()

To ease backports, we rename both constants.

Two new helpers, sk_set_bit(int nr, struct sock *sk)
and sk_clear_bit(int net, struct sock *sk) are added so that
following patch can change their implementation.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

tcp: initialize tp->copied_seq in case of cross SYN connection

2015-11-30T20:34:17+00:00

Dmitry provided a syzkaller (http://github.com/google/syzkaller)
generated program that triggers the WARNING at
net/ipv4/tcp.c:1729 in tcp_recvmsg() :

WARN_ON(tp->copied_seq != tp->rcv_nxt &&
        !(flags & (MSG_PEEK | MSG_TRUNC)));

His program is specifically attempting a Cross SYN TCP exchange,
that we support (for the pleasure of hackers ?), but it looks we
lack proper tcp->copied_seq initialization.

Thanks again Dmitry for your report and testings.

Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Signed-off-by: David S. Miller

net: ipmr, ip6mr: fix vif/tunnel failure race condition

2015-11-24T22:15:56+00:00

Since (at least) commit b17a7c179dd3 ("[NET]: Do sysfs registration as
part of register_netdevice."), netdev_run_todo() deals only with
unregistration, so we don't need to do the rtnl_unlock/lock cycle to
finish registration when failing pimreg or dvmrp device creation. In
fact that opens a race condition where someone can delete the device
while rtnl is unlocked because it's fully registered. The problem gets
worse when netlink support is introduced as there are more points of entry
that can cause it and it also makes reusing that code correctly impossible.

Signed-off-by: Nikolay Aleksandrov 
Reviewed-by: Cong Wang 
Signed-off-by: David S. Miller

net: ipmr: fix static mfc/dev leaks on table destruction

2015-11-23T01:44:46+00:00

When destroying an mrt table the static mfc entries and the static
devices are kept, which leads to devices that can never be destroyed
(because of refcnt taken) and leaked memory, for example:
unreferenced object 0xffff880034c144c0 (size 192):
  comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
  hex dump (first 32 bytes):
    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x4e/0xb0
    [] kmem_cache_alloc+0x190/0x300
    [] ip_mroute_setsockopt+0x5cb/0x910
    [] do_ip_setsockopt.isra.11+0x105/0xff0
    [] ip_setsockopt+0x30/0xa0
    [] raw_setsockopt+0x33/0x90
    [] sock_common_setsockopt+0x14/0x20
    [] SyS_setsockopt+0x71/0xc0
    [] entry_SYSCALL_64_fastpath+0x16/0x7a
    [] 0xffffffffffffffff

Make sure that everything is cleaned on netns destruction.

Signed-off-by: Nikolay Aleksandrov 
Reviewed-by: Cong Wang 
Signed-off-by: David S. Miller

tcp: fix potential huge kmalloc() calls in TCP_REPAIR

2015-11-20T15:57:33+00:00

tcp_send_rcvq() is used for re-injecting data into tcp receive queue.

Problems :

- No check against size is performed, allowed user to fool kernel in
  attempting very large memory allocations, eventually triggering
  OOM when memory is fragmented.

- In case of fault during the copy we do not return correct errno.

Lets use alloc_skb_with_frags() to cook optimal skbs.

Fixes: 292e8d8c8538 ("tcp: Move rcvq sending to tcp_input.c")
Fixes: c0e88ff0f256 ("tcp: Repair socket queues")
Signed-off-by: Eric Dumazet 
Cc: Pavel Emelyanov 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

tcp: fix Fast Open snmp over-counting bug

2015-11-20T15:51:12+00:00

Fix incrementing TCPFastOpenActiveFailed snmp stats multiple times
when the handshake experiences multiple SYN timeouts.

Signed-off-by: Yuchung Cheng 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

tcp: disable Fast Open on timeouts after handshake

2015-11-20T15:51:12+00:00

Some middle-boxes black-hole the data after the Fast Open handshake
(https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf).
The exact reason is unknown. The work-around is to disable Fast Open
temporarily after multiple recurring timeouts with few or no data
delivered in the established state.

Signed-off-by: Yuchung Cheng 
Signed-off-by: Eric Dumazet 
Reported-by: Christoph Paasch 
Signed-off-by: David S. Miller

tcp: md5: fix lockdep annotation

2015-11-19T04:02:47+00:00

When a passive TCP is created, we eventually call tcp_md5_do_add()
with sk pointing to the child. It is not owner by the user yet (we
will add this socket into listener accept queue a bit later anyway)

But we do own the spinlock, so amend the lockdep annotation to avoid
following splat :

[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!
[ 8451.090932]
[ 8451.090932] other info that might help us debug this:
[ 8451.090932]
[ 8451.090934]
[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
[ 8451.090936] 3 locks held by socket_sockopt_/214795:
[ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [] __netif_receive_skb_core+0x151/0xe90
[ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [] ip_local_deliver_finish+0x43/0x2b0
[ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [] sk_clone_lock+0x1c5/0x500
[ 8451.090958]
[ 8451.090958] stack backtrace:
[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_

[ 8451.091215] Call Trace:
[ 8451.091216]    [] dump_stack+0x55/0x76
[ 8451.091229]  [] lockdep_rcu_suspicious+0xeb/0x110
[ 8451.091235]  [] tcp_md5_do_add+0x1bf/0x1e0
[ 8451.091239]  [] tcp_v4_syn_recv_sock+0x1f1/0x4c0
[ 8451.091242]  [] ? tcp_v4_md5_hash_skb+0x167/0x190
[ 8451.091246]  [] tcp_check_req+0x3c8/0x500
[ 8451.091249]  [] ? tcp_v4_inbound_md5_hash+0x11e/0x190
[ 8451.091253]  [] tcp_v4_rcv+0x3c0/0x9f0
[ 8451.091256]  [] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091260]  [] ip_local_deliver_finish+0xb6/0x2b0
[ 8451.091263]  [] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091267]  [] ip_local_deliver+0x48/0x80
[ 8451.091270]  [] ip_rcv_finish+0x160/0x700
[ 8451.091273]  [] ip_rcv+0x29e/0x3d0
[ 8451.091277]  [] __netif_receive_skb_core+0xb47/0xe90

Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU")
Signed-off-by: Eric Dumazet 
Reported-by: Willem de Bruijn 
Signed-off-by: David S. Miller

udp: remove duplicate include

2015-11-18T19:58:02+00:00

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller