Skip to contentSkip to conversation

Race in ip_conntrack_alter_reply

RFC PATCH In review Phil Oester 2 participants 4 messages May 16, 2004 – May 18, 2004

Subsystems (2)
Networking netfilter
lore
Share & tools
lore

Phil Oester

author
#0 lore raw

RFC PATCH 1/1 Race in ip_conntrack_alter_reply

I am still experiencing near daily deadlocks on a few heavily used firewalls here (on all kernels from ~2.4.2x - 2.6.6).

In searching for a solution, I noticed that back in September 2003, Rusty Russell pointed out the possibility of a race in ip_conntrack_alter_reply and offered the below patch.

The relevant threads are:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012368.html
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

And the patch is included below.

It has not yet been included in 2.6 -- should it be??

Phil Oester

Name: ip_conntrack_alter_reply thinko fix
Author: Rusty Russell
Status: Trivial

D: ip_conntrack_alter_reply checks that the reply isn't already taken,
D: but there's little point, since there's *still* a race after it is
D: called (which we handle at confirm time anyway).

include/linux/netfilter_ipv4/ip_conntrack.h +2 -3
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .18239-linux-2.6.0-test5-bk1/include/linux/netfilter_ipv4/ip_conntrack.h .18239-linux-2.6.0-test5-bk1.updated/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -211,9 +211,8 @@ struct ip_conntrack
 /* get master conntrack via master expectation */
 #define master_ct(conntr) (conntr->master ? conntr->master->expectant : NULL)
 
-/* Alter reply tuple (maybe alter helper).  If it's already taken,
-   return 0 and don't do alteration. */
-extern int
+/* Alter reply tuple (maybe alter helper). */
+extern void
 ip_conntrack_alter_reply(struct ip_conntrack *conntrack,
 			 const struct ip_conntrack_tuple *newreply);
net/ipv4/netfilter/ip_conntrack_core.c +4 -10
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .18239-linux-2.6.0-test5-bk1/net/ipv4/netfilter/ip_conntrack_core.c .18239-linux-2.6.0-test5-bk1.updated/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1081,16 +1081,12 @@ int ip_conntrack_change_expect(struct ip
 	return ret;
 }
 
-/* Alter reply tuple (maybe alter helper).  If it's already taken,
-   return 0 and don't do alteration. */
-int ip_conntrack_alter_reply(struct ip_conntrack *conntrack,
-			     const struct ip_conntrack_tuple *newreply)
+/* Alter reply tuple (maybe alter helper).  This is for NAT, and is
+   implicitly racy: see __ip_conntrack_confirm */
+void ip_conntrack_alter_reply(struct ip_conntrack *conntrack,
+			      const struct ip_conntrack_tuple *newreply)
 {
 	WRITE_LOCK(&ip_conntrack_lock);
-	if (__ip_conntrack_find(newreply, conntrack)) {
-		WRITE_UNLOCK(&ip_conntrack_lock);
-		return 0;
-	}
 	/* Should be unconfirmed, so not in hash table yet */
 	IP_NF_ASSERT(!is_confirmed(conntrack));
 

@@ -1103,8 +1099,6 @@ int ip_conntrack_alter_reply(struct ip_c
 					      struct ip_conntrack_helper *,
 					      newreply);
 	WRITE_UNLOCK(&ip_conntrack_lock);
-
-	return 1;
 }
 
 int ip_conntrack_helper_register(struct ip_conntrack_helper *me)
net/ipv4/netfilter/ip_nat_core.c +14 -27

52 lines not on this page · raw message

#1 lore raw

Hi,

2004-05-16, v keltezéssel 23:06-kor Phil Oester ezt írta:

Quoted 7 lines

I am still experiencing near daily deadlocks on a few heavily used firewalls here (on all kernels from ~2.4.2x - 2.6.6).

In searching for a solution, I noticed that back in September 2003, Rusty Russell pointed out the possibility of a race in ip_conntrack_alter_reply and offered the below patch.

Quoted 6 lines

The relevant threads are:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012368.html
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

And the patch is included below.

Does it fix your problems? There were conversations on problems with
ip_nat_setup_info() stuck in endless loop, but I did not experience any problems up to now. Could you provide some more info about your setup?

Signature · 2 lines
 Regards,
   Krisztian KOVACS
author
#2 lore raw

I have not tried the patch yet -- I wanted to see if anyone else thought it looked sane.

Not much unique about my situation -- box with 6 interfaces, one of which is internet link. Pushing about 50mb peak per day...though the box dies at 2 - 6am when traffic is light. Doing nat for a handful of subnets, but most of the /16 is not natted. The box does run OSPF and has ~800 routes in the routing table. What specific info were you looking for?

Phil

Quoted 27 lines · KOVACS Krisztian

Hi,

2004-05-16, v keltezéssel 23:06-kor Phil Oester ezt írta:

Quoted 7 lines

I am still experiencing near daily deadlocks on a few heavily used firewalls here (on all kernels from ~2.4.2x - 2.6.6).

In searching for a solution, I noticed that back in September 2003, Rusty Russell pointed out the possibility of a race in ip_conntrack_alter_reply and offered the below patch.

Quoted 6 lines

The relevant threads are:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012368.html
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

And the patch is included below.

Does it fix your problems? There were conversations on problems with
ip_nat_setup_info() stuck in endless loop, but I did not experience any problems up to now. Could you provide some more info about your setup?

Signature · 2 lines
 Regards,
   Krisztian KOVACS
#3 lore raw

Hi,

2004-05-18, k keltezéssel 16:48-kor Phil Oester ezt írta:

Quoted 2 lines

I have not tried the patch yet -- I wanted to see if anyone else thought it looked sane.

I second that it is sane, but of course my opinion isn't worth a bean.
I've already found that mail in the archives before, while searching for NAT deadlock problems.

Quoted 5 lines

Not much unique about my situation -- box with 6 interfaces, one of which is internet link. Pushing about 50mb peak per day...though the box dies at 2 - 6am when traffic is light. Doing nat for a handful of subnets, but most of the /16 is not natted. The box does run OSPF and has ~800 routes in the routing table. What specific info were you looking for?

Nothing specific. I just wanted to know if you're using
SNAT/DNAT/REDIRECT, and a rough description of the setup.

Signature · 2 lines
 Regards,
   Krisztian KOVACS