On Monday 2012-09-24 22:34, Jim Robinson wrote: > >Can you possibly elaborate on why my initial patch does not actually >fix the problem? Specifically, the concern seems to be that the >values in 'r->master' in limit_mt_check() may not be reliable. In my >testing I saw that r->master was the same (both address and values) >as had been being used in limit_mt() calls for the rule. The ruleset may have already changed by the time the iptables userspace process gets to send in the modified ruleset (with an old r->master). 1. iptables instance 1 fetches ruleset 2. iptables instance 2 flushes the ruleset 3. iptables instance 1 reuploads the ruleset, now with a r->master pointing into the woods. 4. ??? 5. boom. Or, for extra giggles: 1. iptables instance 1 fetches ruleset 2. iptables instance 1 uploads ruleset 3. the new temporary table, i.e. the limit match inside it, (wrongly) reuses r->master 4. the old table frees all its private data. the new limit rule's r->master now points into the woods. 5. ??? 6. boom. >And as something of an aside, can you say why limit_mt_check() is called on all >the rate limit rules when an unrelated iptables change occurs? This is what I >observed. First the new table is constructed, then atomically swapped with the old one, after which the old one is freed. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
