Patchwork iptables: iptables calls setsockopt incorrectly

login
register
mail settings
Submitter Laurence J. Lane
Date Aug. 8, 2013, 5:25 p.m.
Message ID <CA+0KVf052HAN73aMrM95aosN-=49Esam1spX=sUyvd61sDYDRA@mail.gmail.com>
Download mbox | patch
Permalink /patch/265789/
State Not Applicable
Headers show

Comments

Laurence J. Lane - Aug. 8, 2013, 5:25 p.m.
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1187177
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710997


---------- Forwarded message ----------
From: LaMont Jones <lamont@debian.org>
Date: Mon, Jun 3, 2013 at 6:07 PM
Subject: Bug#710997: iptables calls setsockopt incorrectly
To: submit@bugs.debian.org


Package: iptables
Version: 1.4.18-1
Tags: patch
--

Since time immemorial, iptables has called setsockopt() and treated any
-1 return value as fatal.  Any system call can return EAGAIN or
EINPROGRESS (depending on the origins of the API), and good coding
practice requires checking for that and retrying or otherwise handling
it.

In the case of iptables, if multiple processes are calling iptables
concurrently, then it is likely that one of them will fail.  I have seen
this with xen, as well as certain firewall configurations where the
firewall rules are added as triggered by interfaces being discovered and
configured.

The attached patch fixes the issue.
lamont
Pablo Neira - Aug. 8, 2013, 5:29 p.m.
Hi Laurence,

On Thu, Aug 08, 2013 at 01:25:46PM -0400, Laurence J. Lane wrote:
> https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1187177
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710997
> 
> 
> ---------- Forwarded message ----------
> From: LaMont Jones <lamont@debian.org>
> Date: Mon, Jun 3, 2013 at 6:07 PM
> Subject: Bug#710997: iptables calls setsockopt incorrectly
> To: submit@bugs.debian.org
> 
> 
> Package: iptables
> Version: 1.4.18-1
> Tags: patch
> --
> 
> Since time immemorial, iptables has called setsockopt() and treated any
> -1 return value as fatal.  Any system call can return EAGAIN or
> EINPROGRESS (depending on the origins of the API), and good coding
> practice requires checking for that and retrying or otherwise handling
> it.
> 
> In the case of iptables, if multiple processes are calling iptables
> concurrently, then it is likely that one of them will fail.  I have seen
> this with xen, as well as certain firewall configurations where the
> firewall rules are added as triggered by interfaces being discovered and
> configured.

We have these two patch for to address this in mainstream:

http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8
http://git.netfilter.org/iptables/commit/?id=d7aeda5ed45ac7ca959f12180690caa371b5b14b

Regards.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff -ur x/iptables-1.4.18/libiptc/libiptc.c iptables-1.4.18/libiptc/libiptc.c

--- x/iptables-1.4.18/libiptc/libiptc.c	2013-03-03 14:40:11.000000000 -0700

+++ iptables-1.4.18/libiptc/libiptc.c	2013-06-03 16:03:31.819448019 -0600

@@ -2596,8 +2596,10 @@ 

 	}
 #endif
 
-	ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_REPLACE, repl,

+	do {

+		ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_REPLACE, repl,

 			 sizeof(*repl) + repl->size);
+	} while ( ret < 0 && ( errno == EAGAIN || errno == EINPROGRESS));

 	if (ret < 0)
 		goto out_free_newcounters;
 
@@ -2672,8 +2674,10 @@ 

 	}
 #endif
 
-	ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_ADD_COUNTERS,

+	do {

+		ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_ADD_COUNTERS,

 			 newcounters, counterlen);
+	} while ( ret < 0 && ( errno == EAGAIN || errno == EINPROGRESS));

 	if (ret < 0)
 		goto out_free_newcounters;