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
next prev 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.