[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202312081325.1202F2042@keescook>
Date: Fri, 8 Dec 2023 13:27:22 -0800
From: Kees Cook <keescook@...omium.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Bryan Tan <bryantan@...are.com>, Vishnu Dasa <vdasa@...are.com>,
VMware PV-Drivers Reviewers <pv-drivers@...are.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 1/2] VMCI: Remove handle_arr_calc_size()
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@...omium.org>
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.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@...omium.org>
> >
>
--
Kees Cook
Powered by blists - more mailing lists