All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH -stable 0/3] ipvs: patches for stable
@ 2017-05-01 13:45 Julian Anastasov
  2017-05-01 13:45 ` [PATCH 3.2.88,3.4.113 -stable 1/3] ipvs: SNAT packet replies only for NATed connections Julian Anastasov
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Julian Anastasov @ 2017-05-01 13:45 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, Simon Horman, lvs-devel

	Hello,

The following patches are rediffs for "ipvs: SNAT packet replies
only for NATed connections" for different stable kernels:

The official patch for the net tree (will come from Simon) works for:
4.9.25, 4.10.13, 4.11, net tree

Patch 1: 3.2.88, 3.4.113
Patch 2: 3.10.105, 3.12.73, 3.16.43, 4.1.39
Patch 3: 4.4.65

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 3.2.88,3.4.113 -stable 1/3] ipvs: SNAT packet replies only for NATed connections
  2017-05-01 13:45 [PATCH -stable 0/3] ipvs: patches for stable Julian Anastasov
@ 2017-05-01 13:45 ` Julian Anastasov
  2017-05-01 13:45 ` [PATCH 3.10.105,3.12.73,3.16.43,4.1.39 -stable 2/3] " Julian Anastasov
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Julian Anastasov @ 2017-05-01 13:45 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, Simon Horman, lvs-devel

We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:

- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.

- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.

The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.

So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.

Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
 net/netfilter/ipvs/ip_vs_core.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 197ed93..3152091 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -795,10 +795,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 {
 	unsigned int verdict = NF_DROP;
 
-	if (IP_VS_FWD_METHOD(cp) != 0) {
-		pr_err("shouldn't reach here, because the box is on the "
-		       "half connection in the tun/dr module.\n");
-	}
+	if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+		goto ignore_cp;
 
 	/* Ensure the checksum is correct */
 	if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -832,6 +830,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 		ip_vs_notrack(skb);
 	else
 		ip_vs_update_conntrack(skb, cp, 0);
+
+ignore_cp:
 	verdict = NF_ACCEPT;
 
 out:
@@ -1178,8 +1178,11 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af)
 	 */
 	cp = pp->conn_out_get(af, skb, &iph, iph.len, 0);
 
-	if (likely(cp))
+	if (likely(cp)) {
+		if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+			goto ignore_cp;
 		return handle_response(af, skb, pd, cp, iph.len, hooknum);
+	}
 	if (sysctl_nat_icmp_send(net) &&
 	    (pp->protocol == IPPROTO_TCP ||
 	     pp->protocol == IPPROTO_UDP ||
@@ -1225,9 +1228,15 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af)
 			}
 		}
 	}
+
+out:
 	IP_VS_DBG_PKT(12, af, pp, skb, 0,
 		      "ip_vs_out: packet continues traversal as normal");
 	return NF_ACCEPT;
+
+ignore_cp:
+	__ip_vs_conn_put(cp);
+	goto out;
 }
 
 /*
-- 
2.9.3


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 3.10.105,3.12.73,3.16.43,4.1.39 -stable 2/3] ipvs: SNAT packet replies only for NATed connections
  2017-05-01 13:45 [PATCH -stable 0/3] ipvs: patches for stable Julian Anastasov
  2017-05-01 13:45 ` [PATCH 3.2.88,3.4.113 -stable 1/3] ipvs: SNAT packet replies only for NATed connections Julian Anastasov
@ 2017-05-01 13:45 ` Julian Anastasov
  2017-05-01 13:45 ` [PATCH 4.4.65 -stable 3/3] " Julian Anastasov
  2017-05-04 14:09 ` [PATCH -stable 0/3] ipvs: patches for stable Pablo Neira Ayuso
  3 siblings, 0 replies; 7+ messages in thread
From: Julian Anastasov @ 2017-05-01 13:45 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, Simon Horman, lvs-devel

We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:

- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.

- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.

The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.

So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.

Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
 net/netfilter/ipvs/ip_vs_core.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 1c6a71c..ca66520 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -795,10 +795,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 {
 	unsigned int verdict = NF_DROP;
 
-	if (IP_VS_FWD_METHOD(cp) != 0) {
-		pr_err("shouldn't reach here, because the box is on the "
-		       "half connection in the tun/dr module.\n");
-	}
+	if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+		goto ignore_cp;
 
 	/* Ensure the checksum is correct */
 	if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -832,6 +830,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 		ip_vs_notrack(skb);
 	else
 		ip_vs_update_conntrack(skb, cp, 0);
+
+ignore_cp:
 	verdict = NF_ACCEPT;
 
 out:
@@ -1182,8 +1182,11 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af)
 	 */
 	cp = pp->conn_out_get(af, skb, &iph, 0);
 
-	if (likely(cp))
+	if (likely(cp)) {
+		if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+			goto ignore_cp;
 		return handle_response(af, skb, pd, cp, &iph, hooknum);
+	}
 	if (sysctl_nat_icmp_send(net) &&
 	    (pp->protocol == IPPROTO_TCP ||
 	     pp->protocol == IPPROTO_UDP ||
@@ -1225,9 +1228,15 @@ ip_vs_out(unsigned int hooknum, struct sk_buff *skb, int af)
 			}
 		}
 	}
+
+out:
 	IP_VS_DBG_PKT(12, af, pp, skb, 0,
 		      "ip_vs_out: packet continues traversal as normal");
 	return NF_ACCEPT;
+
+ignore_cp:
+	__ip_vs_conn_put(cp);
+	goto out;
 }
 
 /*
-- 
2.9.3


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 4.4.65 -stable 3/3] ipvs: SNAT packet replies only for NATed connections
  2017-05-01 13:45 [PATCH -stable 0/3] ipvs: patches for stable Julian Anastasov
  2017-05-01 13:45 ` [PATCH 3.2.88,3.4.113 -stable 1/3] ipvs: SNAT packet replies only for NATed connections Julian Anastasov
  2017-05-01 13:45 ` [PATCH 3.10.105,3.12.73,3.16.43,4.1.39 -stable 2/3] " Julian Anastasov
@ 2017-05-01 13:45 ` Julian Anastasov
  2017-05-04 14:09 ` [PATCH -stable 0/3] ipvs: patches for stable Pablo Neira Ayuso
  3 siblings, 0 replies; 7+ messages in thread
From: Julian Anastasov @ 2017-05-01 13:45 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, Simon Horman, lvs-devel

We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:

- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.

- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.

The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.

So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.

Reported-by: Nick Moriarty <nick.moriarty@york.ac.uk>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
 net/netfilter/ipvs/ip_vs_core.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 4da5600..dd1649c 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -845,10 +845,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 {
 	unsigned int verdict = NF_DROP;
 
-	if (IP_VS_FWD_METHOD(cp) != 0) {
-		pr_err("shouldn't reach here, because the box is on the "
-		       "half connection in the tun/dr module.\n");
-	}
+	if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+		goto ignore_cp;
 
 	/* Ensure the checksum is correct */
 	if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -882,6 +880,8 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
 		ip_vs_notrack(skb);
 	else
 		ip_vs_update_conntrack(skb, cp, 0);
+
+ignore_cp:
 	verdict = NF_ACCEPT;
 
 out:
@@ -1242,8 +1242,11 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum, struct sk_buff *skb, in
 	 */
 	cp = pp->conn_out_get(ipvs, af, skb, &iph);
 
-	if (likely(cp))
+	if (likely(cp)) {
+		if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+			goto ignore_cp;
 		return handle_response(af, skb, pd, cp, &iph, hooknum);
+	}
 	if (sysctl_nat_icmp_send(ipvs) &&
 	    (pp->protocol == IPPROTO_TCP ||
 	     pp->protocol == IPPROTO_UDP ||
@@ -1285,9 +1288,15 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum, struct sk_buff *skb, in
 			}
 		}
 	}
+
+out:
 	IP_VS_DBG_PKT(12, af, pp, skb, iph.off,
 		      "ip_vs_out: packet continues traversal as normal");
 	return NF_ACCEPT;
+
+ignore_cp:
+	__ip_vs_conn_put(cp);
+	goto out;
 }
 
 /*
-- 
2.9.3


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH -stable 0/3] ipvs: patches for stable
  2017-05-01 13:45 [PATCH -stable 0/3] ipvs: patches for stable Julian Anastasov
                   ` (2 preceding siblings ...)
  2017-05-01 13:45 ` [PATCH 4.4.65 -stable 3/3] " Julian Anastasov
@ 2017-05-04 14:09 ` Pablo Neira Ayuso
  2017-05-04 18:48   ` Julian Anastasov
  3 siblings, 1 reply; 7+ messages in thread
From: Pablo Neira Ayuso @ 2017-05-04 14:09 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: netfilter-devel, Simon Horman, lvs-devel

On Mon, May 01, 2017 at 04:45:34PM +0300, Julian Anastasov wrote:
> 	Hello,
> 
> The following patches are rediffs for "ipvs: SNAT packet replies
> only for NATed connections" for different stable kernels:
> 
> The official patch for the net tree (will come from Simon) works for:
> 4.9.25, 4.10.13, 4.11, net tree
> 
> Patch 1: 3.2.88, 3.4.113
> Patch 2: 3.10.105, 3.12.73, 3.16.43, 4.1.39
> Patch 3: 4.4.65

Thanks Julian.

Could you indicate what upstream commit these patches refer to? stable
maintainer need this.

These are backports, right?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -stable 0/3] ipvs: patches for stable
  2017-05-04 14:09 ` [PATCH -stable 0/3] ipvs: patches for stable Pablo Neira Ayuso
@ 2017-05-04 18:48   ` Julian Anastasov
  2017-05-08  9:50     ` Simon Horman
  0 siblings, 1 reply; 7+ messages in thread
From: Julian Anastasov @ 2017-05-04 18:48 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel, Simon Horman, lvs-devel


	Hello,

On Thu, 4 May 2017, Pablo Neira Ayuso wrote:

> On Mon, May 01, 2017 at 04:45:34PM +0300, Julian Anastasov wrote:
> > 	Hello,
> > 
> > The following patches are rediffs for "ipvs: SNAT packet replies
> > only for NATed connections" for different stable kernels:
> > 
> > The official patch for the net tree (will come from Simon) works for:
> > 4.9.25, 4.10.13, 4.11, net tree
> > 
> > Patch 1: 3.2.88, 3.4.113
> > Patch 2: 3.10.105, 3.12.73, 3.16.43, 4.1.39
> > Patch 3: 4.4.65
> 
> Thanks Julian.
> 
> Could you indicate what upstream commit these patches refer to? stable
> maintainer need this.
> 
> These are backports, right?

	Yes. Simon added the official patch to the ipvs tree and
the next step is to post it to you. May be you have to defer
these backports. If needed, I can send them again later.

Regards

--
Julian Anastasov <ja@ssi.bg>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH -stable 0/3] ipvs: patches for stable
  2017-05-04 18:48   ` Julian Anastasov
@ 2017-05-08  9:50     ` Simon Horman
  0 siblings, 0 replies; 7+ messages in thread
From: Simon Horman @ 2017-05-08  9:50 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: Pablo Neira Ayuso, netfilter-devel, lvs-devel

On Thu, May 04, 2017 at 09:48:08PM +0300, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Thu, 4 May 2017, Pablo Neira Ayuso wrote:
> 
> > On Mon, May 01, 2017 at 04:45:34PM +0300, Julian Anastasov wrote:
> > > 	Hello,
> > > 
> > > The following patches are rediffs for "ipvs: SNAT packet replies
> > > only for NATed connections" for different stable kernels:
> > > 
> > > The official patch for the net tree (will come from Simon) works for:
> > > 4.9.25, 4.10.13, 4.11, net tree
> > > 
> > > Patch 1: 3.2.88, 3.4.113
> > > Patch 2: 3.10.105, 3.12.73, 3.16.43, 4.1.39
> > > Patch 3: 4.4.65
> > 
> > Thanks Julian.
> > 
> > Could you indicate what upstream commit these patches refer to? stable
> > maintainer need this.
> > 
> > These are backports, right?
> 
> 	Yes. Simon added the official patch to the ipvs tree and
> the next step is to post it to you. May be you have to defer
> these backports. If needed, I can send them again later.

Hi Pablo,

sorry for the confusion. I have now posted the fix for you to consider for
mainline. Please see "[GIT PULL 0/1] IPVS Fixes for v4.12".

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-05-08  9:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-01 13:45 [PATCH -stable 0/3] ipvs: patches for stable Julian Anastasov
2017-05-01 13:45 ` [PATCH 3.2.88,3.4.113 -stable 1/3] ipvs: SNAT packet replies only for NATed connections Julian Anastasov
2017-05-01 13:45 ` [PATCH 3.10.105,3.12.73,3.16.43,4.1.39 -stable 2/3] " Julian Anastasov
2017-05-01 13:45 ` [PATCH 4.4.65 -stable 3/3] " Julian Anastasov
2017-05-04 14:09 ` [PATCH -stable 0/3] ipvs: patches for stable Pablo Neira Ayuso
2017-05-04 18:48   ` Julian Anastasov
2017-05-08  9:50     ` Simon Horman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.