From: Len Baker <len.baker@gmx.com>
To: Kees Cook <keescook@chromium.org>
Cc: Len Baker <len.baker@gmx.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michael Straube <straube.linux@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 2/2] staging/rtl8192u: Prefer kcalloc over open coded arithmetic
Date: Sun, 22 Aug 2021 17:41:02 +0200 [thread overview]
Message-ID: <20210822154044.GA8942@titan> (raw)
In-Reply-To: <202108220751.4E6ADBA@keescook>
Hi Kees,
On Sun, Aug 22, 2021 at 07:59:51AM -0700, Kees Cook wrote:
> On Sun, Aug 22, 2021 at 04:28:20PM +0200, Len Baker wrote:
> > Dynamic size calculations (especially multiplication) should not be
> > performed in memory allocator (or similar) function arguments due to the
> > risk of them overflowing. This could lead to values wrapping around and
> > a smaller allocation being made than the caller was expecting. Using
> > those allocations could lead to linear overflows of heap memory and
> > other misbehaviors.
> >
> > So, use the purpose specific kcalloc() function instead of the argument
> > size * count in the kzalloc() function.
>
> It might be useful to reference the documentation on why this change is
> desired:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Ok, I will add this info to the next version. Thanks for the advise.
> Here and in the docs, though, it's probably worth noting that these
> aren't actually dynamic sizes: both sides of the multiplication are
> constant values. I still think it's best to refactor these anyway, just
> to keep the open-coded math idiom out of code, though.
Ok, I will change the commit message to note this. Also I will send
a patch to add this info to the documentation.
> Also, have you looked at Coccinelle at all? I have a hideous pile of
> rules that try to find these instances, but it really needs improvement:
> https://github.com/kees/coccinelle-linux-allocator-overflow/tree/trunk/array_size
I think my script is even worst ;) but find some arithmetic to improve :)
I will take a look. Thanks for the info.
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
Regards,
Len
> >
> > Signed-off-by: Len Baker <len.baker@gmx.com>
> > ---
> > drivers/staging/rtl8192u/r819xU_phy.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192u/r819xU_phy.c b/drivers/staging/rtl8192u/r819xU_phy.c
> > index ff6fe2ee3349..97f4d89500ae 100644
> > --- a/drivers/staging/rtl8192u/r819xU_phy.c
> > +++ b/drivers/staging/rtl8192u/r819xU_phy.c
> > @@ -1195,17 +1195,17 @@ static u8 rtl8192_phy_SwChnlStepByStep(struct net_device *dev, u8 channel,
> > u8 e_rfpath;
> > bool ret;
> >
> > - pre_cmd = kzalloc(sizeof(*pre_cmd) * MAX_PRECMD_CNT, GFP_KERNEL);
> > + pre_cmd = kcalloc(MAX_PRECMD_CNT, sizeof(*pre_cmd), GFP_KERNEL);
> > if (!pre_cmd)
> > return false;
> >
> > - post_cmd = kzalloc(sizeof(*post_cmd) * MAX_POSTCMD_CNT, GFP_KERNEL);
> > + post_cmd = kcalloc(MAX_POSTCMD_CNT, sizeof(*post_cmd), GFP_KERNEL);
> > if (!post_cmd) {
> > kfree(pre_cmd);
> > return false;
> > }
> >
> > - rf_cmd = kzalloc(sizeof(*rf_cmd) * MAX_RFDEPENDCMD_CNT, GFP_KERNEL);
> > + rf_cmd = kcalloc(MAX_RFDEPENDCMD_CNT, sizeof(*rf_cmd), GFP_KERNEL);
> > if (!rf_cmd) {
> > kfree(pre_cmd);
> > kfree(post_cmd);
> > --
> > 2.25.1
> >
>
> --
> Kees Cook
prev parent reply other threads:[~2021-08-22 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-22 14:28 [PATCH 0/2] staging/rtl8192u: Prefer kcalloc over open coded arithmetic Len Baker
2021-08-22 14:28 ` [PATCH 1/2] staging/rtl8192u: Avoid CamelCase in names of variables Len Baker
2021-08-22 15:02 ` Kees Cook
2021-08-23 8:54 ` Dan Carpenter
2021-08-22 14:28 ` [PATCH 2/2] staging/rtl8192u: Prefer kcalloc over open coded arithmetic Len Baker
2021-08-22 14:59 ` Kees Cook
2021-08-22 15:41 ` Len Baker [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=20210822154044.GA8942@titan \
--to=len.baker@gmx.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=lee.jones@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=straube.linux@gmail.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.