From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: Michal Kubecek <mkubecek@suse.cz>,
andrea.mattiazzo@suse.com, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Eric Dumazet <edumazet@google.com>,
coreteam@netfilter.org, netfilter-devel@vger.kernel.org,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [netfilter-core] [PATCH net] netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval()
Date: Tue, 6 Feb 2024 12:30:58 +0100 [thread overview]
Message-ID: <ZcIYcqjcFDqjvRZ3@calendula> (raw)
In-Reply-To: <ZcIYL3Z/rx+/iJg0@calendula>
On Tue, Feb 06, 2024 at 12:29:51PM +0100, Pablo Neira Ayuso wrote:
> On Tue, Feb 06, 2024 at 12:11:12PM +0100, Florian Westphal wrote:
> > Michal Kubecek <mkubecek@suse.cz> wrote:
> > > I stumbled upon this when the issue got a CVE id (sigh) and I share
> > > Andrea's (Cc-ed) concern that the fix is incomplete. While the fix,
> > > commit c301f0981fdd ("netfilter: nf_tables: fix pointer math issue in
> > > nft_byteorder_eval()") now, fixes the destination side, src is still
> > > a pointer to u32, i.e. we are reading 64-bit values with relative
> > > offsets which are multiples of 32 bits.
> > >
> > > Shouldn't we fix this as well, e.g. like indicated below?
> >
> > No, please remove multi-elem support instead, nothing uses this feature.
>
> See attached patch.
>
> I posted this:
>
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20240202120602.5122-1-pablo@netfilter.org/
>
> I can replace it by the attached patch if you prefer. This can only
> help in the future to microoptimize some set configurations, where
> several byteorder can be coalesced into one single expression.
I have to replace those index 'i' by simply dst instead, this is
obviosly incomplete.
> diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c
> index 8cf91e47fd7a..af3412602869 100644
> --- a/net/netfilter/nft_byteorder.c
> +++ b/net/netfilter/nft_byteorder.c
> @@ -43,18 +43,14 @@ void nft_byteorder_eval(const struct nft_expr *expr,
>
> switch (priv->op) {
> case NFT_BYTEORDER_NTOH:
> - for (i = 0; i < priv->len / 8; i++) {
> - src64 = nft_reg_load64(&src[i]);
> - nft_reg_store64(&dst64[i],
> - be64_to_cpu((__force __be64)src64));
> - }
> + src64 = nft_reg_load64(&src[i]);
> + nft_reg_store64(&dst64[i],
> + be64_to_cpu((__force __be64)src64));
> break;
> case NFT_BYTEORDER_HTON:
> - for (i = 0; i < priv->len / 8; i++) {
> - src64 = (__force __u64)
> - cpu_to_be64(nft_reg_load64(&src[i]));
> - nft_reg_store64(&dst64[i], src64);
> - }
> + src64 = (__force __u64)
> + cpu_to_be64(nft_reg_load64(&src[i]));
> + nft_reg_store64(&dst64[i], src64);
> break;
> }
> break;
> @@ -62,24 +58,20 @@ void nft_byteorder_eval(const struct nft_expr *expr,
> case 4:
> switch (priv->op) {
> case NFT_BYTEORDER_NTOH:
> - for (i = 0; i < priv->len / 4; i++)
> - dst[i] = ntohl((__force __be32)src[i]);
> + dst[i] = ntohl((__force __be32)src[i]);
> break;
> case NFT_BYTEORDER_HTON:
> - for (i = 0; i < priv->len / 4; i++)
> - dst[i] = (__force __u32)htonl(src[i]);
> + dst[i] = (__force __u32)htonl(src[i]);
> break;
> }
> break;
> case 2:
> switch (priv->op) {
> case NFT_BYTEORDER_NTOH:
> - for (i = 0; i < priv->len / 2; i++)
> - d16[i] = ntohs((__force __be16)s16[i]);
> + d16[i] = ntohs((__force __be16)s16[i]);
> break;
> case NFT_BYTEORDER_HTON:
> - for (i = 0; i < priv->len / 2; i++)
> - d16[i] = (__force __u16)htons(s16[i]);
> + d16[i] = (__force __u16)htons(s16[i]);
> break;
> }
> break;
> @@ -137,6 +129,9 @@ static int nft_byteorder_init(const struct nft_ctx *ctx,
> if (err < 0)
> return err;
>
> + if (priv->size != len)
> + return -EINVAL;
> +
> priv->len = len;
>
> if (len % size != 0)
prev parent reply other threads:[~2024-02-06 11:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 6:42 [PATCH net] netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval() Dan Carpenter
2023-11-03 9:18 ` Florian Westphal
2023-11-03 9:45 ` Pablo Neira Ayuso
2023-11-03 10:25 ` Florian Westphal
2024-02-06 10:43 ` Michal Kubecek
2024-02-06 11:04 ` Dan Carpenter
2024-02-06 11:09 ` Michal Kubecek
2024-02-06 11:11 ` Florian Westphal
2024-02-06 11:29 ` Pablo Neira Ayuso
2024-02-06 11:30 ` Pablo Neira Ayuso [this message]
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=ZcIYcqjcFDqjvRZ3@calendula \
--to=pablo@netfilter.org \
--cc=andrea.mattiazzo@suse.com \
--cc=coreteam@netfilter.org \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kadlec@netfilter.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.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).