From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Kal Cutter Conley <kal.conley@dectris.com>
Cc: "Björn Töpel" <bjorn@kernel.org>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xsk: Add missing overflow check in xdp_umem_reg
Date: Wed, 8 Mar 2023 14:32:40 +0100 [thread overview]
Message-ID: <968526f7-d262-b69e-ca72-f56078158000@intel.com> (raw)
In-Reply-To: <CAHApi-kcvc2qB0D6dV7OG99FsnzAEa-rchOMfySkZ-E=EOh_4w@mail.gmail.com>
From: Kal Conley <kal.conley@dectris.com>
Date: Tue, 7 Mar 2023 19:58:51 +0100
>> The RCT declaration style is messed up in the whole block. Please move
>> lines around, there's nothing wrong in that.
>
> I think I figured out what this is. Is this preference documented
> somewhere? I will fix it.
It's when you sort the declarations by the line length. I.e.
short var a;
longest var b;
medium var c;
=>
longest var b;
medium var c;
short var a;
I think it's documented somewhere in the kernel. You can try grepping by
"Reverse Christmas Tree".
>
>>
>>> int err;
>>>
>>> if (chunk_size < XDP_UMEM_MIN_CHUNK_SIZE || chunk_size > PAGE_SIZE) {
>>> @@ -188,8 +189,8 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
>>> if (npgs > U32_MAX)
>>> return -EINVAL;
>>>
>>> - chunks = (unsigned int)div_u64_rem(size, chunk_size, &chunks_rem);
>>> - if (chunks == 0)
>>> + chunks = div_u64_rem(size, chunk_size, &chunks_rem);
>>> + if (chunks == 0 || chunks > U32_MAX)
>>
>> You can change the first cond to `!chunks` while at it, it's more
>> preferred than `== 0`.
>
> If you want, I can change it. I generally like to keep unrelated
> changes to a minimum.
You modify the line either way, so I don't see any reasons to keep the
code as-is. It's clear that replacing `== 0` to `!chunks` won't change
the logic anyhow.
>
>>
>>> return -EINVAL;
>>
>> Do you have any particular bugs that the current code leads to? Or it's
>> just something that might hypothetically happen?
>
> If the UMEM is large enough, the code is broke. Maybe it can be
> exploited somehow? It should be checked for exactly the same reasons
> as `npgs` right above it.
>
>>
>>>
>>> if (!unaligned_chunks && chunks_rem)
>>> @@ -201,7 +202,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
>>> umem->size = size;
>>> umem->headroom = headroom;
>>> umem->chunk_size = chunk_size;
>>> - umem->chunks = chunks;
>>> + umem->chunks = (u32)chunks;
>>
>> You already checked @chunks fits into 32 bits, so the cast can be
>> omitted here, it's redundant.
>
> I made it consistent with the line right below it. It seems like the
> cast may improve readability since it makes it known the truncation is
> on purpose. I don't see how that is redundant with the safety check.
> Should I change both lines?
I'd prefer to change both lines. You already check both @npgs and
@chunks for being <= %U32_MAX and anyone can see it from the code, so
the casts don't make anything more readable.
>
>>
>>> umem->npgs = (u32)npgs;
>>> umem->pgs = NULL;
>>> umem->user = NULL;
>>
>> Thanks,
>> Olek
>
> Kal
Thanks,
Olek
next prev parent reply other threads:[~2023-03-08 13:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 17:23 Kal Conley
2023-03-07 17:47 ` Alexander Lobakin
2023-03-07 18:58 ` Kal Cutter Conley
2023-03-08 13:32 ` Alexander Lobakin [this message]
2023-03-08 10:51 ` Kal Conley
2023-03-08 15:33 ` Alexander Lobakin
2023-03-08 18:49 ` Kal Cutter Conley
2023-03-09 16:30 ` Alexander Lobakin
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=968526f7-d262-b69e-ca72-f56078158000@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kal.conley@dectris.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@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
all inboxes | Powered by JetHome®