From: Kees Cook <keescook@chromium.org>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Bryan Tan <bryantan@vmware.com>, Vishnu Dasa <vdasa@vmware.com>,
VMware PV-Drivers Reviewers <pv-drivers@vmware.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1/2] VMCI: Remove handle_arr_calc_size()
Date: Fri, 8 Dec 2023 13:27:22 -0800 [thread overview]
Message-ID: <202312081325.1202F2042@keescook> (raw)
In-Reply-To: <7fee5580-37ad-4c0a-b1d2-f45b592f86a4@wanadoo.fr>
On Fri, Dec 08, 2023 at 10:14:35PM +0100, Christophe JAILLET wrote:
> Le 08/12/2023 à 21:59, Kees Cook a écrit :
> > On Fri, Dec 08, 2023 at 09:46:09PM +0100, Christophe JAILLET wrote:
> > > Use struct_size() instead of handle_arr_calc_size().
> > > This is much more conventionnal.
> > >
> > > Suggested-by: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> >
> > Looks good. And since capacity in u32, there's no need for size_add().
>
> Hmm,
>
> isn't u32 + u32 --> u32, so can overflow?
> If I understand correctly, the type promotion to size_t will occur after the
> addition.
Oh lovely, I thought the promotion was first. Ugh.
> So size_add() looks needed, or I missed something?
Yeah, and I'm also to stuck in pretending 32-bit systems don't exist.
So, yes, please include size_add()...
-Kees
>
> CJ
>
> >
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> >
>
--
Kees Cook
prev parent reply other threads:[~2023-12-08 21:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 20:46 [PATCH 1/2] VMCI: Remove handle_arr_calc_size() Christophe JAILLET
2023-12-08 20:46 ` [PATCH 2/2] VMCI: Remove VMCI_HANDLE_ARRAY_HEADER_SIZE and VMCI_HANDLE_ARRAY_MAX_CAPACITY Christophe JAILLET
2023-12-08 20:59 ` Kees Cook
2023-12-08 20:59 ` [PATCH 1/2] VMCI: Remove handle_arr_calc_size() Kees Cook
2023-12-08 21:14 ` Christophe JAILLET
2023-12-08 21:27 ` Kees Cook [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=202312081325.1202F2042@keescook \
--to=keescook@chromium.org \
--cc=arnd@arndb.de \
--cc=bryantan@vmware.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pv-drivers@vmware.com \
--cc=vdasa@vmware.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 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.