From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jesper Dangaard Brouer <hawk@diku.dk>
Cc: hawk@comx.dk, netfilter-devel@lists.netfilter.org,
Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH] BUG: libiptc chain references bug
Date: Mon, 17 Jul 2006 00:31:39 +0200 [thread overview]
Message-ID: <44BABE4B.70008@netfilter.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0607162125500.31595@ask.diku.dk>
Jesper Dangaard Brouer wrote:
> On Sun, 16 Jul 2006, Pablo Neira Ayuso wrote:
>> Jesper Dangaard Brouer wrote:
>>>
>>> Correcting a chain references increment bug in libiptc.
>>>
>>> The bug lies in function iptc_delete_entry() / TC_DELETE_ENTRY. The
>>> problem is the construction of "r" the rule entry, that is used for
>>> comparison. The problem is that the function iptcc_map_target()
>>> increase the target chains references count.
>>>
>>> The fix is to use function iptcc_delete_rule() to delete the "r" rule
>>> (as it decrement the counter again). To make it work a small NULL
>>> pointer check is also added iptcc_delete_rule().
>>>
>>> Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
>>
>>
>> I don't like too much the is-the-rule-in-list checking in
>> delete_entry, please, could you tell me what you think about the patch
>> attached? I think it's cleaner. Thanks.
>
> First of all, (no offence) your patch will not work, as it does not
> catch all control-flow cases. That is, if no match was found your patch
> does not decrement the refcount. Hint, look at the places free(r) is
> called.
You are right, I missed that exit path.
> I have attached a patch, that does catch all cases. This is achived by
> adding a else statement to the if statement where iptcc_map_target is
> called.
I think I prefer this one, let see what Patrick thinks.
> I did consider, your strategy, but the reason I decided not to, was that
> I though it was cleaner to always call "iptcc_delete_rule" when we want
> to delete a rule, instead of free'ing it manually.
>
> Well, I think Patrick should make the decision. As long as we fix the
> bug, I don't care which patch goes in.
>
> Cheers,
> Jesper Brouer
>
> p.s. Pablo, I was not going to piss in the bush... I was just discussing
> with Gert Hansen about how dry the plant was... Perhaps the plant would
> have preferred that I would have taken a leak... See you around ;-)
That bush surely would prefer it these damned hot days of summer 8)
--
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
next prev parent reply other threads:[~2006-07-16 22:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-12 15:25 BUG: libiptc chain references bug Jesper Dangaard Brouer
2006-07-13 11:17 ` Jesper Dangaard Brouer
2006-07-14 12:29 ` [PATCH] " Jesper Dangaard Brouer
2006-07-16 15:01 ` Pablo Neira Ayuso
2006-07-16 20:19 ` Jesper Dangaard Brouer
2006-07-16 22:31 ` Pablo Neira Ayuso [this message]
2006-07-20 16:52 ` Patrick McHardy
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=44BABE4B.70008@netfilter.org \
--to=pablo@netfilter.org \
--cc=hawk@comx.dk \
--cc=hawk@diku.dk \
--cc=kaber@trash.net \
--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.