| Message ID | CA+0KVf052HAN73aMrM95aosN-=49Esam1spX=sUyvd61sDYDRA@mail.gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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
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;
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