All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: SaifAllah benMassaoud <saifmassaoudi18@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	security@kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [SECURITY] netfilter: nft_limit byte-rate bypass via unchecked u64 multiplication
Date: Sun, 11 Oct 2026 21:14:01 +0200	[thread overview]
Message-ID: <asvf-crRnd2ReH9c@strlen.de> (raw)
In-Reply-To: <CADikNYA74Zco-PnTvQOih+=A-Hq6ZCV1oyoC+xszGJy756gzMw@mail.gmail.com>

SaifAllah benMassaoud <saifmassaoudi18@gmail.com> wrote:
> My security concern is that an administrator may configure this limit to
> protect a service, yet a less-privileged sender could circumvent the
> intended rate enforcement by sending packets of specific sizes, without
> modifying the ruleset.

Why would anyone use 'per week' rates...?

N packets/s.
N packets/minute
N packets/hour.

.. make sense to me.

But even N packets/day is dubious. with that kind of limitation, why
would you even log in the first place?

The byte rate limiting is for traffic policing, i.e. N bytes / second.
The obvious 'fix' for your case is to reject the rule add.

diff --git a/net/netfilter/nft_limit.c b/net/netfilter/nft_limit.c
--- a/net/netfilter/nft_limit.c
+++ b/net/netfilter/nft_limit.c
@@ -73,6 +73,10 @@ static int nft_limit_init(struct nft_limit_priv *priv,
        if (check_mul_overflow(unit, NSEC_PER_SEC, &priv->nsecs))
                return -EOVERFLOW;

+       if (!pkts &&
+           check_mul_overflow(priv->nsecs, GRO_MAX_SIZE, &tmp))
+               return -EOVERFLOW;
+
        if (tb[NFTA_LIMIT_BURST])

but I agree with Pablo, this is not a security issue.
Consider testing the above and then submitting that as a patch,
targetting nf-next tree.

  reply	other threads:[~2026-10-11 19:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 17:01 [SECURITY] netfilter: nft_limit byte-rate bypass via unchecked u64 multiplication SaifAllah benMassaoud
2026-10-11  7:34 ` Pablo Neira Ayuso
     [not found]   ` <CADikNYCzQRErYLwDLoUPrDs8dmuBB8z+45yxKAaps7QTCrLXXA@mail.gmail.com>
2026-10-11 16:55     ` Pablo Neira Ayuso
     [not found]       ` <CADikNYBiijxQjptcYf-2+omXj8Mf5PTGVwK-Ho53E7JEe_ehvQ@mail.gmail.com>
2026-10-11 18:23         ` SaifAllah benMassaoud
2026-10-11 19:14           ` Florian Westphal [this message]
     [not found]             ` <CADikNYDzCg46TWPk0dAXQF-Yar+FgEegWEzFZvzCp3x7-k_mOg@mail.gmail.com>
     [not found]               ` <CADikNYBZ5MqJWypk5NFYcxYvPKJhKKyJ5iOWN4JTZrUWf1AUAQ@mail.gmail.com>
2026-10-11 21:11                 ` Pablo Neira Ayuso
     [not found]                   ` <CADikNYC4P0F7gz4nCxKcJwsAzXEEA-a-8QRu1TE3SUzXvmcuZA@mail.gmail.com>
2026-10-11 21:43                     ` Pablo Neira Ayuso
2026-10-11 22:08                       ` 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=asvf-crRnd2ReH9c@strlen.de \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=saifmassaoudi18@gmail.com \
    --cc=security@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 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.