linux-stable.git/net/netfilter/ipvs, branch linux-2.6.32.y

ipvs: uninitialized data with IP_VS_IPV6

2015-05-24T08:10:52+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: Ben Hutchings 
Cc: Pablo Neira Ayuso 
(cherry picked from commit 0ce625baeec39e813bef9b073f0214b513b2ef2d)
Signed-off-by: Willy Tarreau

ipvs: fix CHECKSUM_PARTIAL for TCP, UDP

2014-05-19T05:53:12+00:00

 	Fix CHECKSUM_PARTIAL handling. Tested for IPv4 TCP,
UDP not tested because it needs network card with HW CSUM support.
May be fixes problem where IPVS can not be used in virtual boxes.
Problem appears with DNAT to local address when the local stack
sends reply in CHECKSUM_PARTIAL mode.

 	Fix tcp_dnat_handler and udp_dnat_handler to provide
vaddr and daddr in right order (old and new IP) when calling
tcp_partial_csum_update/udp_partial_csum_update (CHECKSUM_PARTIAL).

Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
(cherry picked from commit 5bc9068e9d962ca6b8bec3f0eb6f60ab4dee1d04)
Signed-off-by: Willy Tarreau

ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)

2013-06-10T09:43:39+00:00

commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 upstream.

If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is
not set, __ip_vs_get_timeouts() does not fully initialize the structure
that gets copied to userland and that for leaks up to 12 bytes of kernel
stack. Add an explicit memset(0) before passing the structure to
__ip_vs_get_timeouts() to avoid the info leak.

Signed-off-by: Mathias Krause 
Cc: Wensong Zhang 
Cc: Simon Horman 
Cc: Julian Anastasov 
Signed-off-by: David S. Miller 
[bwh: Backported to 2.6.32: adjust context]
Signed-off-by: Willy Tarreau

ipvs: IPv6 MTU checking cleanup and bugfix

2013-06-10T09:43:39+00:00

Cleaning up the IPv6 MTU checking in the IPVS xmit code, by using
a common helper function __mtu_check_toobig_v6().

The MTU check for tunnel mode can also use this helper as
ntohs(old_iph->payload_len) + sizeof(struct ipv6hdr) is qual to
skb->len.  And the 'mtu' variable have been adjusted before
calling helper.

Notice, this also fixes a bug, as the the MTU check in ip_vs_dr_xmit_v6()
were missing a check for skb_is_gso().

This bug e.g. caused issues for KVM IPVS setups, where different
Segmentation Offloading techniques are utilized, between guests,
via the virtio driver.  This resulted in very bad performance,
due to the ICMPv6 "too big" messages didn't affect the sender.

Signed-off-by: Jesper Dangaard Brouer 
Signed-off-by: Patrick McHardy 
Signed-off-by: Pablo Neira Ayuso 
(cherry picked from commit 590e3f79a21edd2e9857ac3ced25ba6b2a491ef8)
Signed-off-by: Willy Tarreau

ipvs: allow transmit of GRO aggregated skbs

2013-06-10T09:43:38+00:00

Attempt at allowing LVS to transmit skbs of greater than MTU length that
have been aggregated by GRO and can thus be deaggregated by GSO.

Cc: Julian Anastasov 
Cc: Herbert Xu 
Signed-off-by: Simon Horman 
(cherry picked from commit 8f1b03a4c18e8f3f0801447b62330faa8ed3bb37)
Signed-off-by: Willy Tarreau

ipvs: Add missing locking during connection table hashing and unhashing

2010-08-02T17:20:50+00:00

commit aea9d711f3d68c656ad31ab578ecfb0bb5cd7f97 upstream.

The code that hashes and unhashes connections from the connection table
is missing locking of the connection being modified, which opens up a
race condition and results in memory corruption when this race condition
is hit.

Here is what happens in pretty verbose form:

CPU 0					CPU 1
------------				------------
An active connection is terminated and
we schedule ip_vs_conn_expire() on this
CPU to expire this connection.

					IRQ assignment is changed to this CPU,
					but the expire timer stays scheduled on
					the other CPU.

					New connection from same ip:port comes
					in right before the timer expires, we
					find the inactive connection in our
					connection table and get a reference to
					it. We proper lock the connection in
					tcp_state_transition() and read the
					connection flags in set_tcp_state().

ip_vs_conn_expire() gets called, we
unhash the connection from our
connection table and remove the hashed
flag in ip_vs_conn_unhash(), without
proper locking!

					While still holding proper locks we
					write the connection flags in
					set_tcp_state() and this sets the hashed
					flag again.

ip_vs_conn_expire() fails to expire the
connection, because the other CPU has
incremented the reference count. We try
to re-insert the connection into our
connection table, but this fails in
ip_vs_conn_hash(), because the hashed
flag has been set by the other CPU. We
re-schedule execution of
ip_vs_conn_expire(). Now this connection
has the hashed flag set, but isn't
actually hashed in our connection table
and has a dangling list_head.

					We drop the reference we held on the
					connection and schedule the expire timer
					for timeouting the connection on this
					CPU. Further packets won't be able to
					find this connection in our connection
					table.

					ip_vs_conn_expire() gets called again,
					we think it's already hashed, but the
					list_head is dangling and while removing
					the connection from our connection table
					we write to the memory location where
					this list_head points to.

The result will probably be a kernel oops at some other point in time.

This race condition is pretty subtle, but it can be triggered remotely.
It needs the IRQ assignment change or another circumstance where packets
coming from the same ip:port for the same service are being processed on
different CPUs. And it involves hitting the exact time at which
ip_vs_conn_expire() gets called. It can be avoided by making sure that
all packets from one connection are always processed on the same CPU and
can be made harder to exploit by changing the connection timeouts to
some custom values.

Signed-off-by: Sven Wegener 
Acked-by: Simon Horman 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

ipvs: zero usvc and udest

2009-12-18T22:05:51+00:00

commit 258c889362aa95d0ab534b38ce8c15d3009705b1 upstream.

Make sure that any otherwise uninitialised fields of usvc are zero.

This has been obvserved to cause a problem whereby the port of
fwmark services may end up as a non-zero value which causes
scheduling of a destination server to fail for persisitent services.

As observed by Deon van der Merwe .
This fix suggested by Julian Anastasov .

For good measure also zero udest.

Cc: Deon van der Merwe 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

sysctl: remove "struct file *" argument of ->proc_handler

2009-09-24T14:21:04+00:00

It's unused.

It isn't needed -- read or write flag is already passed and sysctl
shouldn't care about the rest.

It _was_ used in two places at arch/frv for some reason.

Signed-off-by: Alexey Dobriyan 
Cc: David Howells 
Cc: "Eric W. Biederman" 
Cc: Al Viro 
Cc: Ralf Baechle 
Cc: Martin Schwidefsky 
Cc: Ingo Molnar 
Cc: "David S. Miller" 
Cc: James Morris 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

IPVS: Add handling of incoming ICMPV6 messages

2009-08-31T14:22:23+00:00

Add handling of incoming ICMPv6 messages.
This follows the handling of IPv4 ICMP messages.

Amongst ther things this problem allows IPVS to behave sensibly
when an ICMPV6_PKT_TOOBIG message is received:

This message is received when a realserver sends a packet >PMTU to the
client. The hop on this path with insufficient MTU will generate an
ICMPv6 Packet Too Big message back to the VIP. The LVS server receives
this message, but the call to the function handling this has been
missing. Thus, IPVS fails to forward the message to the real server,
which then does not adjust the path MTU. This patch adds the missing
call to ip_vs_in_icmp_v6() in ip_vs_in() to handle this situation.

Thanks to Rob Gallagher from HEAnet for reporting this issue and for
testing this patch in production (with direct routing mode).

[horms@verge.net.au: tweaked changelog]
Signed-off-by: Julius Volz 
Tested-by: Rob Gallagher 
Signed-off-by: Simon Horman 
Signed-off-by: Patrick McHardy

ipvs: Use atomic operations atomicly

2009-08-31T12:18:48+00:00

A pointed out by Shin Hong, IPVS doesn't always use atomic operations
in an atomic manner. While this seems unlikely to be manifest in
strange behaviour, it seems appropriate to clean this up.

Cc: shin hong 
Signed-off-by: Simon Horman 
Signed-off-by: Patrick McHardy