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

ipvs: count pre-established TCP states as active

2016-09-29T09:14:20+00:00

commit be2cef49904b34dd5f75d96bbc8cd8341bab1bc0 upstream.

Some users observed that "least connection" distribution algorithm doesn't
handle well bursts of TCP connections from reconnecting clients after
a node or network failure.

This is because the algorithm counts active connection as worth 256
inactive ones where for TCP, "active" only means TCP connections in
ESTABLISHED state. In case of a connection burst, new connections are
handled before previous ones have finished the three way handshaking so
that all are still counted as "inactive", i.e. cheap ones. The become
"active" quickly but at that time, all of them are already assigned to one
real server (or few), resulting in highly unbalanced distribution.

Address this by counting the "pre-established" states as "active".

Signed-off-by: Michal Kubecek 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

ipvs: correct initial offset of Call-ID header search in SIP persistence engine

2016-05-11T09:37:32+00:00

commit 7617a24f83b5d67f4dab1844956be1cebc44aec8 upstream.

The IPVS SIP persistence engine is not able to parse the SIP header
"Call-ID" when such header is inserted in the first positions of
the SIP message.

When IPVS is configured with "--pe sip" option, like for example:
ipvsadm -A -u 1.2.3.4:5060 -s rr --pe sip -p 120 -o
some particular messages (see below for details) do not create entries
in the connection template table, which can be listed with:
ipvsadm -Lcn --persistent-conn

Problematic SIP messages are SIP responses having "Call-ID" header
positioned just after message first line:
SIP/2.0 200 OK
[Call-ID header here]
[rest of the headers]

When "Call-ID" header is positioned down (after a few other headers)
it is correctly recognized.

This is due to the data offset used in get_callid function call inside
ip_vs_pe_sip.c file: since dptr already points to the start of the
SIP message, the value of dataoff should be initially 0.
Otherwise the header is searched starting from some bytes after the
first character of the SIP message.

Fixes: 758ff0338722 ("IPVS: sip persistence engine")
Signed-off-by: Marco Angaroni 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Slaby

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