linux-stable.git/net/netfilter/ipvs, branch v3.12.52

ipvs: fix crash with sync protocol v0 and FTP

2015-10-28T15:37:59+00:00

commit 56184858d1fc95c46723436b455cb7261cd8be6f upstream.

Fix crash in 3.5+ if FTP is used after switching
sync_version to 0.

Fixes: 749c42b620a9 ("ipvs: reduce sync rate with time thresholds")
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: do not use random local source address for tunnels

2015-10-28T15:37:59+00:00

commit 4754957f04f5f368792a0eb7dab0ae89fb93dcfd upstream.

Michael Vallaly reports about wrong source address used
in rare cases for tunneled traffic. Looks like
__ip_vs_get_out_rt in 3.10+ is providing uninitialized
dest_dst->dst_saddr.ip because ip_vs_dest_dst_alloc uses
kmalloc. While we retry after seeing EINVAL from routing
for data that does not look like valid local address, it
still succeeded when this memory was previously used from
other dests and with different local addresses. As result,
we can use valid local address that is not suitable for
our real server.

Fix it by providing 0.0.0.0 every time our cache is refreshed.
By this way we will get preferred source address from routing.

Reported-by: Michael Vallaly 
Fixes: 026ace060dfe ("ipvs: optimize dst usage for real server")
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: rerouting to local clients is not needed anymore

2015-03-10T16:21:38+00:00

[ upstream commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa ]

commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
ip_send_reply()." from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.

Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
"3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"

Cc:  # 3.10.x
Cc:  # 3.12.x
Cc:  # 3.14.x
Cc:  # 3.18.x
Reported-by: Smart Weblications GmbH - Florian Wiessner 
Tested-by: Smart Weblications GmbH - Florian Wiessner 
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: add missing ip_vs_pe_put in sync code

2015-03-10T16:21:38+00:00

[ upstream commit 528c943f3bb919aef75ab2fff4f00176f09a4019 ]

ip_vs_conn_fill_param_sync() gets in param.pe a module
reference for persistence engine from __ip_vs_pe_getbyname()
but forgets to put it. Problem occurs in backup for
sync protocol v1 (2.6.39).

Also, pe_data usually comes in sync messages for
connection templates and ip_vs_conn_new() copies
the pointer only in this case. Make sure pe_data
is not leaked if it comes unexpectedly for normal
connections. Leak can happen only if bogus messages
are sent to backup server.

Fixes: fe5e7a1efb66 ("IPVS: Backup, Adding Version 1 receive capability")
Cc:  # 3.10.x
Cc:  # 3.12.x
Cc:  # 3.14.x
Cc:  # 3.18.x
Cc:  # 3.19.x
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: uninitialized data with IP_VS_IPV6

2015-01-29T14:45:09+00:00

commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.

The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.

The same issue is there in app_tcp_pkt_in().  Thanks to Julian Anastasov
for noticing that.

Signed-off-by: Dan Carpenter 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: correct usage/allocation of seqadj ext in ipvs

2015-01-26T14:04:50+00:00

[ upstream commit b25adce1606427fd88da08f5203714cada7f6a98 ]

The IPVS FTP helper ip_vs_ftp could trigger an OOPS in nf_ct_seqadj_set,
after commit 41d73ec053d2 (netfilter: nf_conntrack: make sequence number
adjustments usuable without NAT).

This is because, the seqadj ext is now allocated dynamically, and the
IPVS code didn't handle this situation.  Fix this in the IPVS nfct
code by invoking the alloc function nfct_seqadj_ext_add().

Cc:  # 3.12.x
Fixes: 41d73ec053d2 (netfilter: nf_conntrack: make sequence number adjustments usuable without NAT)
Suggested-by: Julian Anastasov 
Signed-off-by: Jesper Dangaard Brouer 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: fix ipv6 hook registration for local replies

2014-09-26T10:31:57+00:00

commit eb90b0c734ad793d5f5bf230a9e9a4dcc48df8aa upstream.

commit fc604767613b6d2036cdc35b660bc39451040a47
("ipvs: changes for local real server") from 2.6.37
introduced DNAT support to local real server but the
IPv6 LOCAL_OUT handler ip_vs_local_reply6() is
registered incorrectly as IPv4 hook causing any outgoing
IPv4 traffic to be dropped depending on the IP header values.

Chris tracked down the problem to CONFIG_IP_VS_IPV6=y
Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768

Reported-by: Chris J Arges 
Tested-by: Chris J Arges 
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

2014-09-26T10:31:50+00:00

commit 76f084bc10004b3050b2cff9cfac29148f1f6088 upstream.

Previously, only the four high bits of the tclass were maintained in the
ipv6 case.  This matches the behavior of ipv4, though whether or not we
should reflect ECN bits may be up for debate.

Signed-off-by: Alex Gartrell 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: avoid netns exit crash on ip_vs_conn_drop_conntrack

2014-09-26T10:31:41+00:00

commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream.

commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack")
added second ip_vs_conn_drop_conntrack call instead of just adding
the needed check. As result, the first call still can cause
crash on netns exit. Remove it.

Signed-off-by: Julian Anastasov 
Signed-off-by: Hans Schillstrom 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

inetpeer: get rid of ip_id_count

2014-08-19T15:15:00+00:00

[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

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