netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org, Fabio <pedretti.fabio@gmail.com>
Subject: Re: [nf-next PATCH 2/2] netfilter: xt_recent: Largely lift restrictions on max hitcount value
Date: Fri, 14 Jun 2024 12:45:27 +0200	[thread overview]
Message-ID: <ZmwfRzlY1xUbJCmR@orbyte.nwl.cc> (raw)
In-Reply-To: <20240613144105.GA27366@breakpoint.cc>

On Thu, Jun 13, 2024 at 04:41:05PM +0200, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > Support tracking of up to 2^32-1 packets per table. Since users provide
> > the hitcount value in a __u32 variable, they can't exceed the max value
> > anymore.
> > 
> > Requested-by: Fabio <pedretti.fabio@gmail.com>
> > Link: https://bugzilla.netfilter.org/show_bug.cgi?id=1745
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  net/netfilter/xt_recent.c | 15 +++++----------
> >  1 file changed, 5 insertions(+), 10 deletions(-)
> > 
> > diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
> > index 60259280b2d5..77ac4964e2dc 100644
> > --- a/net/netfilter/xt_recent.c
> > +++ b/net/netfilter/xt_recent.c
> > @@ -59,9 +59,9 @@ MODULE_PARM_DESC(ip_list_gid, "default owning group of /proc/net/xt_recent/* fil
> >  /* retained for backwards compatibility */
> >  static unsigned int ip_pkt_list_tot __read_mostly;
> >  module_param(ip_pkt_list_tot, uint, 0400);
> > -MODULE_PARM_DESC(ip_pkt_list_tot, "number of packets per IP address to remember (max. 255)");
> > +MODULE_PARM_DESC(ip_pkt_list_tot, "number of packets per IP address to remember (max. 2^32 - 1)");
> >  
> > -#define XT_RECENT_MAX_NSTAMPS	256
> > +#define XT_RECENT_MAX_NSTAMPS	(1ULL << 32)
> 
> Won't that allow massive mem hog?

You're right, struct recent_entry may become ~32GB in size.

> Actually I think this is already a mem hog, unbounded
> allocations from time where we had no untrusted netns :-(

With the current max of 255 stamps, entries are at max 1KB in size. Is
this bad already? Given unrestricted rule counts, there are various ways
to cause large memory allocation, no?

How about restricting MAX_NSTAMPS to 1<<16? Max entry size is 568B, a
little less insane than th 32GB I thoughtlessly proposed above. :)

Cheers, Phil

  reply	other threads:[~2024-06-14 10:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13 14:32 [nf-next PATCH 0/2] netfilter: xt_recent: Allow for much larger hitcount values Phil Sutter
2024-06-13 14:32 ` [nf-next PATCH 1/2] netfilter: xt_reent: Reduce size of struct recent_entry::nstamps Phil Sutter
2024-06-13 14:32 ` [nf-next PATCH 2/2] netfilter: xt_recent: Largely lift restrictions on max hitcount value Phil Sutter
2024-06-13 14:41   ` Florian Westphal
2024-06-14 10:45     ` Phil Sutter [this message]
2024-06-17 17:38   ` kernel test robot

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=ZmwfRzlY1xUbJCmR@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pedretti.fabio@gmail.com \
    /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).