iptables+2.6-test8-bk4 : Still problems

iptables+2.6-test8-bk4 : Still problems

[Georg Chini]

Hello,

on my sparc64 (ultra1) I am using ppp and ipsec
to get a tunnel to my office. Before 2.6.0-test8-bk4
my computer would freeze when using any iptables command.
With 2.6.0-test8-bk4 "iptables -F" responds with
"invalid argument" when my ppp interface is up and
the tables will not be flushed.
/usr/local/sbin/iptables -A INPUT -i ppp0 -j ACCEPT
works, but the corresponding
/usr/local/sbin/iptables -D INPUT -i ppp0 -j ACCEPT
does not, again I get "invalid argument".
When I additionally start ipsec (using freeswan 2.03)
things will get worse. Every iptables command referring
to the ppp interface or the IP-address of the ppp interface
is rejected with "invalid argument".
Any suggestions how to fix this are welcome.
If you need more debugging output, I can supply it.
As I am not sure wether this is a sparc-only problem,
I post this to netfilter-devel too.

Thanks in advance
                   Georg Chini

Re: iptables+2.6-test8-bk4 : Still problems

[Balint Cristian]

On Sunday 26 October 2003 03:48, Georg Chini wrote:

> /usr/local/sbin/iptables -A INPUT -i ppp0 -j ACCEPT
> works, but the corresponding
> /usr/local/sbin/iptables -D INPUT -i ppp0 -j ACCEPT
> does not, again I get "invalid argument".


I object too, a simple "iptables -F" not work, see here:

-------------------------------------------///-------------------------------------
[root@sun root]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:631 reject-with tcp-reset

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
[root@sun root]# iptables -F INPUT
iptables: No chain/target/match by that name
[root@sun root]#
------------------------------------////------------------------------------------------------------

	I can add rules even can delete rules, accounting seems to work on rules but only rules FLUSH
don't work.

Using: iptables v1.2.8 + 2.6.0-test8-bk2 + davem.netfilter-compat-patch

cristian


>
> Thanks in advance
>                    Georg Chini
>
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Life in itself has no meaning. 
Life is an opportunity to create meaning.

              \|/ ____ \|/ 
              "@'/ .. \`@" 
              /_| \__/ |_\ 
                 \__U_/ 

Re: iptables+2.6-test8-bk4 : Still problems

[David S. Miller]

It's some bug in the translation code in net/compat.c

If someone could review that code and try to find the bug
I'd appreciate it as I have a million other things to do
over the next few days.

Thanks.

Re: iptables+2.6-test8-bk4 : Still problems

[Georg Chini]

David S. Miller wrote:
> It's some bug in the translation code in net/compat.c

Yes it is.
The problem is, that the ipt_entries are not all the same
size. So instead of copying them one by one you have
to copy the whole block. Here is a patch:


--- linux-test/net/compat.c     Tue Oct 28 21:15:36 2003
+++ linux-2.6.0-test9/net/compat.c      Tue Oct 28 20:52:43 2003
@@ -318,11 +318,12 @@
  {
         struct compat_ipt_replace *urepl = (struct compat_ipt_replace *)optval;
         struct ipt_replace *repl_nat;
+       struct ipt_entry *k_ipt_entries;
         char name[IPT_TABLE_MAXNAMELEN];
         u32 origsize, tmp32, num_counters;
         unsigned int repl_nat_size;
         int ret;
-       int i, num_ents;
+       int i;
         compat_uptr_t ucntrs;

         if (get_user(origsize, &urepl->size))
@@ -366,15 +367,14 @@
             __put_user(compat_ptr(ucntrs), &repl_nat->counters))
                 goto out;

-       num_ents = origsize / sizeof(struct ipt_entry);
-
-       for (i = 0; i < num_ents; i++) {
-               struct ipt_entry ent;
+       k_ipt_entries = (struct ipt_entry *)kmalloc(origsize, GFP_KERNEL);
+       if (__copy_from_user(k_ipt_entries, &urepl->entries[0], origsize) ||
+           __copy_to_user(&repl_nat->entries[0], k_ipt_entries, origsize)) {
+               kfree(k_ipt_entries);
+               goto out;
+               }

-               if (__copy_from_user(&ent, &urepl->entries[i], sizeof(ent)) ||
-                   __copy_to_user(&repl_nat->entries[i], &ent, sizeof(ent)))
-                       goto out;
-       }
+       kfree(k_ipt_entries);

         for (i = 0; i < NF_IP_NUMHOOKS; i++) {
                 if (__get_user(tmp32, &urepl->hook_entry[i]) ||

Re: iptables+2.6-test8-bk4 : Still problems

[David S. Miller]

On Tue, 28 Oct 2003 21:31:02 +0100
Georg Chini <georg.chini@triaton-webhosting.com> wrote:

> David S. Miller wrote:
> > It's some bug in the translation code in net/compat.c
> 
> Yes it is.
> The problem is, that the ipt_entries are not all the same
> size. So instead of copying them one by one you have
> to copy the whole block. Here is a patch:

Good spotting, I didn't know this.

However, I was trying to avoid a kmalloc of anything in this code :(
You're also not verifying the kmalloc() return value for errors.

I think I'll use copy_in_user() to fix this bug, thanks.

Re: iptables+2.6-test8-bk4 : Still problems

[David S. Miller]

Ok, here is the patch I'm using to fix this, please test.

Thanks again for figuring out the problem Georg.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1380  -> 1.1381 
#	        net/compat.c	1.11    -> 1.12   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/28	davem@nuts.ninka.net	1.1381
# [NET/COMPAT]: Fix copying of ipt_entry objects in do_netfilter_replace().
# 
# As noted by Georg Chini, ipt_entry object are of variable size
# so just copying individual struct ipt_entry slots around does
# not work.
# --------------------------------------------
#
diff -Nru a/net/compat.c b/net/compat.c
--- a/net/compat.c	Tue Oct 28 23:16:40 2003
+++ b/net/compat.c	Tue Oct 28 23:16:40 2003
@@ -322,7 +322,7 @@
 	u32 origsize, tmp32, num_counters;
 	unsigned int repl_nat_size;
 	int ret;
-	int i, num_ents;
+	int i;
 	compat_uptr_t ucntrs;
 
 	if (get_user(origsize, &urepl->size))
@@ -366,15 +366,10 @@
 	    __put_user(compat_ptr(ucntrs), &repl_nat->counters))
 		goto out;
 
-	num_ents = origsize / sizeof(struct ipt_entry);
-
-	for (i = 0; i < num_ents; i++) {
-		struct ipt_entry ent;
-
-		if (__copy_from_user(&ent, &urepl->entries[i], sizeof(ent)) ||
-		    __copy_to_user(&repl_nat->entries[i], &ent, sizeof(ent)))
-			goto out;
-	}
+	if (__copy_in_user(&repl_nat->entries[0],
+			   &urepl->entries[0],
+			   origsize))
+		goto out;
 
 	for (i = 0; i < NF_IP_NUMHOOKS; i++) {
 		if (__get_user(tmp32, &urepl->hook_entry[i]) ||

Re: iptables+2.6-test8-bk4 : Still problems

[Ryan Veety]

On Tue, 28 Oct 2003, David S. Miller wrote:

>
> Ok, here is the patch I'm using to fix this, please test.
>
> Thanks again for figuring out the problem Georg.

Works here, -F flushes properly.  The only remaining netfilter issue I noticed
is limiting doesn't work on sparc64.  The following works fine on an x86
machine running 2.6.0-test9.

# iptables -A INPUT -i eth0 -p icmp -m limit --limit 10/second -j ACCEPT
iptables: Invalid argument

No biggie for me, just happened to notice it.

Ryan
     __________________________________________________________
   .'  Ryan Veety <ryan@ryanspc.com> - http://www.ryanspc.com  `.
   |          PGP Key: http://www.ryanspc.com/pgp.txt           |
    `----------------------------------------------------------'

Re: iptables+2.6-test8-bk4 : Still problems

[David S. Miller]

On Wed, 29 Oct 2003 13:20:30 -0500 (EST)
Ryan Veety <ryan@ryanspc.com> wrote:

> # iptables -A INPUT -i eth0 -p icmp -m limit --limit 10/second -j ACCEPT
> iptables: Invalid argument
> 
> No biggie for me, just happened to notice it.

I suspect it's the "unsigned long" in "struct ipt_rateinfo", we'd need
to translate these structures going in/out of netfilter :-(

There are a bunch of other iptables target modules that would need
similar translations.