All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira <pablo@eurodev.net>
To: Henrik Nordstrom <hno@marasystems.com>
Cc: netfilter-devel@lists.netfilter.org, Fang Han <fanghan@opencjk.org>
Subject: Re: [BUG] ipt_SAME rule can't be deleted
Date: Tue, 07 Dec 2004 13:27:51 +0100	[thread overview]
Message-ID: <41B5A1C7.5060608@eurodev.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0412060821280.10926@filer.marasystems.com>

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

  parent reply	other threads:[~2004-12-07 12:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-04 15:02 [BUG] ipt_SAME rule can't be deleted Fang Han
2004-12-06  7:34 ` Henrik Nordstrom
2004-12-06 20:59   ` Samuel Jean
2004-12-16 12:42     ` Harald Welte
2004-12-07 12:27   ` Pablo Neira [this message]
2004-12-07 15:47     ` Henrik Nordstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41B5A1C7.5060608@eurodev.net \
    --to=pablo@eurodev.net \
    --cc=fanghan@opencjk.org \
    --cc=hno@marasystems.com \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.