[iptables] iptables: fix undersized deletion mask creation
Patrick McHardy
netfilter-cvslog-bounces at lists.netfilter.org
Thu Oct 29 23:55:39 CET 2009
Gitweb: http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commit;h=4f0d7b660e0ae8f678142fd2a1722b27ad472169
commit 4f0d7b660e0ae8f678142fd2a1722b27ad472169
Author: Jan Engelhardt <jengelh at medozas.de>
AuthorDate: Tue Oct 27 02:59:33 2009 +0100
Commit: Jan Engelhardt <jengelh at medozas.de>
CommitDate: Thu Oct 29 19:04:00 2009 +0100
iptables: fix undersized deletion mask creation
The mask created for the -D rulespec is simply too small.
xtables_targets points to whatever target has last been loaded, so
xtables_targets->size is quite almost wrong, as we need to use the
size of the target for the specific rule that is about to be deleted.
This bug existed ever since iptables history is tracked, and requires
certain circumstances to be visible, where the deletion operation is
one. Furthermore, multiple userspace target extensions must have been
loaded, and a target B whose .size is smaller than the target A of
the rule we are about to delete must have been loaded more recently
than target A. The minimal testcase is (rule 60007 gets wrongly
removed)
*nat
-F
-X
-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60007
-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
-A POSTROUTING -p udp -j CONNMARK --set-mark 0
-D POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
COMMIT
References: http://bugzilla.netfilter.org/show_bug.cgi?id=606
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 7c4d668c9c2ee007c82063b7fc784cbbf46b2ec4
Author: Jan Engelhardt <jengelh at medozas.de>
AuthorDate: Mon Oct 26 18:43:54 2009 +0100
Commit: Jan Engelhardt <jengelh at medozas.de>
CommitDate: Thu Oct 29 19:04:00 2009 +0100
libiptc: fix wrong maptype of base chain counters on restore
When a ruleset that does not reset any chain policies/counters, such as
*filter
COMMIT
is sourced by iptables-restore, the previous policy and counters
(i.e. the ones read from the kernel) are reused. The counter skew
offsetting is wrong however, causing the read value to be readded to
the kernel value. This manifests itself in practice by the counter
value almost doubling everytime iptables-restore is called.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 58df90174164fd673e8c4103f7ce0c4e55ef1aec
Author: Olaf Rempel <razzor at kopf-tisch.de>
AuthorDate: Sun Sep 20 13:24:11 2009 +0200
Commit: Jan Engelhardt <jengelh at medozas.de>
CommitDate: Thu Oct 29 19:04:00 2009 +0100
build: restore --disable-ipv6 functionality on system w/o v6 headers
Commit 332e4acc (iptables: accept multiple IP address specifications
for -s, d) broke the --disable-ipv6 configure option.
> ./.libs/libxtables.so: undefined reference to `in6addr_any'
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 467060c1543d25638186c085fc60e492182ca028
Author: Jan Engelhardt <jengelh at medozas.de>
AuthorDate: Thu Oct 29 19:03:38 2009 +0100
Commit: Jan Engelhardt <jengelh at medozas.de>
CommitDate: Thu Oct 29 19:03:38 2009 +0100
iprange: warn on reverse range (log)
Reverse ranges like B-A cause packets to be generally never matched,
as an address S does not match >=B && <=A (except for the border case
where S=A=B).
The kernel module itself does not check for reverse ranges, and it
seems nicer to check that in userspace anyway.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit f8ff2d12707a5d4215731a1ed90780e62ad8263e
Author: Jan Engelhardt <jengelh at medozas.de>
AuthorDate: Sun Oct 25 11:34:55 2009 +0100
Commit: Jan Engelhardt <jengelh at medozas.de>
CommitDate: Sun Oct 25 11:34:55 2009 +0100
iprange: do accept non-ranges for xt_iprange v1 (log)
Details for commit v1.4.5-11-ga10a12a:
"When upgraded to new lenny kernel from 2.6.24 from etch'n'half
iprange now does not allow to use single ip-address as its argument:
# iptables -A FORWARD -m iprange --src-range 192.168.0.0"
References: http://bugs.debian.org/547139
What we have here is that the user is now using iprange v1 from
previously v0.
Add recognition for single addresses to v1.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
via 4f0d7b660e0ae8f678142fd2a1722b27ad472169 (commit)
via 7c4d668c9c2ee007c82063b7fc784cbbf46b2ec4 (commit)
via 58df90174164fd673e8c4103f7ce0c4e55ef1aec (commit)
via 467060c1543d25638186c085fc60e492182ca028 (commit)
via f8ff2d12707a5d4215731a1ed90780e62ad8263e (commit)
from 7fa7329fc972513021131416dbd9d535141bd2ea (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 4f0d7b660e0ae8f678142fd2a1722b27ad472169
Author: Jan Engelhardt <jengelh at medozas.de>
Date: Tue Oct 27 02:59:33 2009 +0100
iptables: fix undersized deletion mask creation
The mask created for the -D rulespec is simply too small.
xtables_targets points to whatever target has last been loaded, so
xtables_targets->size is quite almost wrong, as we need to use the
size of the target for the specific rule that is about to be deleted.
This bug existed ever since iptables history is tracked, and requires
certain circumstances to be visible, where the deletion operation is
one. Furthermore, multiple userspace target extensions must have been
loaded, and a target B whose .size is smaller than the target A of
the rule we are about to delete must have been loaded more recently
than target A. The minimal testcase is (rule 60007 gets wrongly
removed)
*nat
-F
-X
-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60007
-A POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
-A POSTROUTING -p udp -j CONNMARK --set-mark 0
-D POSTROUTING -p udp -j SNAT --to 192.168.1.1:60008
COMMIT
References: http://bugzilla.netfilter.org/show_bug.cgi?id=606
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 7c4d668c9c2ee007c82063b7fc784cbbf46b2ec4
Author: Jan Engelhardt <jengelh at medozas.de>
Date: Mon Oct 26 18:43:54 2009 +0100
libiptc: fix wrong maptype of base chain counters on restore
When a ruleset that does not reset any chain policies/counters, such as
*filter
COMMIT
is sourced by iptables-restore, the previous policy and counters
(i.e. the ones read from the kernel) are reused. The counter skew
offsetting is wrong however, causing the read value to be readded to
the kernel value. This manifests itself in practice by the counter
value almost doubling everytime iptables-restore is called.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 58df90174164fd673e8c4103f7ce0c4e55ef1aec
Author: Olaf Rempel <razzor at kopf-tisch.de>
Date: Sun Sep 20 13:24:11 2009 +0200
build: restore --disable-ipv6 functionality on system w/o v6 headers
Commit 332e4acc (iptables: accept multiple IP address specifications
for -s, d) broke the --disable-ipv6 configure option.
> ./.libs/libxtables.so: undefined reference to `in6addr_any'
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit 467060c1543d25638186c085fc60e492182ca028
Author: Jan Engelhardt <jengelh at medozas.de>
Date: Thu Oct 29 19:03:38 2009 +0100
iprange: warn on reverse range (log)
Reverse ranges like B-A cause packets to be generally never matched,
as an address S does not match >=B && <=A (except for the border case
where S=A=B).
The kernel module itself does not check for reverse ranges, and it
seems nicer to check that in userspace anyway.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
commit f8ff2d12707a5d4215731a1ed90780e62ad8263e
Author: Jan Engelhardt <jengelh at medozas.de>
Date: Sun Oct 25 11:34:55 2009 +0100
iprange: do accept non-ranges for xt_iprange v1 (log)
Details for commit v1.4.5-11-ga10a12a:
"When upgraded to new lenny kernel from 2.6.24 from etch'n'half
iprange now does not allow to use single ip-address as its argument:
# iptables -A FORWARD -m iprange --src-range 192.168.0.0"
References: http://bugs.debian.org/547139
What we have here is that the user is now using iprange v1 from
previously v0.
Add recognition for single addresses to v1.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
-----------------------------------------------------------------------
ip6tables.c | 14 ++++++++------
iptables.c | 14 ++++++++------
libiptc/libiptc.c | 2 +-
xtables.c | 3 ++-
4 files changed, 19 insertions(+), 14 deletions(-)
Details for commit v1.4.5-11-ga10a12a:
"When upgraded to new lenny kernel from 2.6.24 from etch'n'half
iprange now does not allow to use single ip-address as its argument:
# iptables -A FORWARD -m iprange --src-range 192.168.0.0"
References: http://bugs.debian.org/547139
What we have here is that the user is now using iprange v1 from
previously v0.
Add recognition for single addresses to v1.
Signed-off-by: Jan Engelhardt <jengelh at medozas.de>
More information about the netfilter-cvslog
mailing list