[BUG] ipt_SAME rule can't be deleted

[BUG] ipt_SAME rule can't be deleted

[Fang Han]

Kernel 2.6.9 ac2

Using the next test command:

/sbin/iptables  -t nat -I POSTROUTING -s 192.168.100.23 -o eth0 -j SAME --to 192.168.1.60
/sbin/iptables  -t nat -D POSTROUTING -s 192.168.100.23 -o eth0 -j SAME --to 192.168.1.60

generate error:
iptables: Bad rule (does a matching rule exist in that chain?)

But I can use iptables -t nat -D POSTROUTING 1 to delete this rules

Re: [BUG] ipt_SAME rule can't be deleted

[Henrik Nordstrom]

On Sat, 4 Dec 2004, Fang Han wrote:

> Kernel 2.6.9 ac2
>
> Using the next test command:
>
> /sbin/iptables  -t nat -I POSTROUTING -s 192.168.100.23 -o eth0 -j SAME --to 192.168.1.60
> /sbin/iptables  -t nat -D POSTROUTING -s 192.168.100.23 -o eth0 -j SAME --to 192.168.1.60
>
> generate error:
> iptables: Bad rule (does a matching rule exist in that chain?)

This is quite likely due to that kernel land pointer within the target 
info...

         u_int32_t *iparray;

If I am right the same problem applies to -m limit and any other extension 
storing private kernel side stuff within it's info data..

Regards
Henrik

Re: [BUG] ipt_SAME rule can't be deleted

[Samuel Jean]

On Mon, December 6, 2004 2:34 am, Henrik Nordstrom said:

>          u_int32_t *iparray;
>
> If I am right the same problem applies to -m limit and any other extension
> storing private kernel side stuff within it's info data..
>

If I am right too,
This wouldn't happen if we moved u_int32_t *iparray at end of structure.
Then, registering the target plugin that way :

    .size            = IPT_ALIGN(sizeof(struct ipt_same_info)),
    .userspacesize   = offsetof(struct ipt_same_info, iparray),

Would fix this inconveniant.


> Regards
> Henrik
>
Best regards,

Samuel
CookingLinux TM

Re: [BUG] ipt_SAME rule can't be deleted

[Pablo Neira]

Henrik Nordstrom wrote:

> On Sat, 4 Dec 2004, Fang Han wrote:
>
>> Kernel 2.6.9 ac2
>>
>> Using the next test command:
>>
>> /sbin/iptables  -t nat -I POSTROUTING -s 192.168.100.23 -o eth0 -j 
>> SAME --to 192.168.1.60
>> /sbin/iptables  -t nat -D POSTROUTING -s 192.168.100.23 -o eth0 -j 
>> SAME --to 192.168.1.60
>>
>> generate error:
>> iptables: Bad rule (does a matching rule exist in that chain?)
>
>
> This is quite likely due to that kernel land pointer within the target 
> info...
>
>         u_int32_t *iparray;
>
> If I am right the same problem applies to -m limit and any other 
> extension storing private kernel side stuff within it's info data..


Right, we bite the dust when having pointers within the target private 
info... If we try to remove a rule, it won't match the existing because 
in user space that pointer is set to NULL, but in kernel space is set to 
whatever kmalloc reserved the space for us.

In iptables, target_difference() complains because, in the case of 
ipt_same, iparray isn't NULL. Same thing with iplimit. I think that in 
pkttables we need a private info part for match/targets which is not 
shared with user space.

--
Pablo

Re: [BUG] ipt_SAME rule can't be deleted

[Henrik Nordstrom]

On Tue, 7 Dec 2004, Pablo Neira wrote:

> In iptables, target_difference() complains because, in the case of ipt_same, 
> iparray isn't NULL. Same thing with iplimit. I think that in pkttables we 
> need a private info part for match/targets which is not shared with user 
> space.

As already pointed out iptables actually have a similar concept, but the 
kernel data must be at the end, and userspace must know the total size to 
allocate it properly within the table..

limit uses this correctly.

SAME does not.

In addition, pointers is hazardous as the opinion on the size may differ 
between kernel and userland on certain architectures. Only fixed size 
items should be used in iptables target/match info structures. C unions 
can make this somewhat manageable.

Regards
Henrik

Re: [BUG] ipt_SAME rule can't be deleted

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Mon, Dec 06, 2004 at 03:59:45PM -0500, Samuel Jean wrote:
> On Mon, December 6, 2004 2:34 am, Henrik Nordstrom said:
> 
> >          u_int32_t *iparray;
> >
> > If I am right the same problem applies to -m limit and any other extension
> > storing private kernel side stuff within it's info data..
> >
> 
> If I am right too,
> This wouldn't happen if we moved u_int32_t *iparray at end of structure.
> Then, registering the target plugin that way :
> 
>     .size            = IPT_ALIGN(sizeof(struct ipt_same_info)),
>     .userspacesize   = offsetof(struct ipt_same_info, iparray),
> 
> Would fix this inconveniant.

Unfortunately we cannot just change the order now, since then we run
into all the back/forward compatibility issues again...

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]