From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 2/3] netfilter: nf_tables: check for overflow of rule dlen field
Date: Thu, 5 Mar 2015 18:42:39 +0100 [thread overview]
Message-ID: <20150305174239.GA7411@salvia> (raw)
In-Reply-To: <20150305171352.GD29092@acer.localdomain>
On Thu, Mar 05, 2015 at 05:13:53PM +0000, Patrick McHardy wrote:
> I think this case shouldn't exist at all since it codifies kernel
> internals into the API. Today we might accept 128 expressions, the
> other day just 100, all depending on 32 or 64 bit systems. Its not
> good.
>
> The problem is I also don't want to increase the maximum rule size
> to more than 4k since this will run into issues with memory
> fragmentation. I think we need to decrease NFT_EXPR_MAXNUM, its
> unreasonable large, and then add a per expression maximum size.
Yes, that's more than anyone would need I guess. We used to have a
couple of crazy tests in iptables with lots of matches in one rule
(maps to one expression each) that were hitting the limit. So my
motivation was to avoid hitting that it from nft_compat. Assuming that
the info area consumes ~32 bytes and 128 expressions, we would exactly
reach the limit. But there are xtables extensions consuming more than
that for the info area, so we may hit the limit before those 128
expressions with this check. I think that's OK, we should consider
realistic scenarios, not too crazy tests.
> For now I'd say apply it as it is, keep the different errno code
> since its a really different case, and we'll fix up the underlying
> problem after a bit more of thought.
Sure, thanks for the explanation.
next prev parent reply other threads:[~2015-03-05 17:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 20:04 [PATCH 0/3] netfilter: nf_tables fixes Patrick McHardy
2015-03-03 20:04 ` [PATCH 1/3] netfilter: nf_tables: fix transaction race condition Patrick McHardy
2015-03-04 16:18 ` Pablo Neira Ayuso
2015-03-04 16:26 ` Patrick McHardy
2015-03-04 17:01 ` Pablo Neira Ayuso
2015-03-04 17:03 ` Patrick McHardy
2015-03-04 17:28 ` Pablo Neira Ayuso
2015-03-04 17:36 ` Patrick McHardy
2015-03-04 17:38 ` Patrick McHardy
2015-03-03 20:04 ` [PATCH 2/3] netfilter: nf_tables: check for overflow of rule dlen field Patrick McHardy
2015-03-05 16:31 ` Pablo Neira Ayuso
2015-03-05 16:31 ` Patrick McHardy
2015-03-05 17:11 ` Pablo Neira Ayuso
2015-03-05 17:13 ` Patrick McHardy
2015-03-05 17:42 ` Pablo Neira Ayuso [this message]
2015-03-05 18:15 ` Patrick McHardy
2015-03-03 20:04 ` [PATCH 3/3] netfilter: nf_tables: fix userdata length overflow Patrick McHardy
2015-03-05 20:23 ` [PATCH 0/3] netfilter: nf_tables fixes Pablo Neira Ayuso
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=20150305174239.GA7411@salvia \
--to=pablo@netfilter.org \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).