MIME-Version: 1.0
References: <20230226132500.3933232-1-void0red@gmail.com> <Y/w16PI4klfJaeXA@kadam>
In-Reply-To: <Y/w16PI4klfJaeXA@kadam>
From:   Kang Chen <void0red@gmail.com>
Date:   Mon, 27 Feb 2023 15:11:21 +0800
Message-ID: <CANE+tVpqZusCq4EXi7UV+jY0XBG+9x6UWh_JGCWKs3pZRMFBXA@mail.gmail.com>
Subject: Re: [PATCH] staging: r8188eu: add a null check of kzalloc in go_add_group_info_attr
To:     Dan Carpenter <error27@gmail.com>
Cc:     paskripkin@gmail.com, Larry.Finger@lwfinger.net,
        phil@philpotter.co.uk, gregkh@linuxfoundation.org,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi, Dan,

Thanks for your review.
I noticed there is no error handling in the origin design (this call chain)=
.
go_add_group_info_attr returns a len-like value indicating the length
of pbuf.
I don't think throwing an error to the caller is a good idea, the caller
doesn't seem to care about it.
So inserting a netdev_dbg or pr_debug here might be enough.
Do you have a better idea?

Best regards,
Kang Chen


On Mon, Feb 27, 2023 at 12:47=E2=80=AFPM Dan Carpenter <error27@gmail.com> =
wrote:
>
> On Sun, Feb 26, 2023 at 09:25:00PM +0800, Kang Chen wrote:
> > kzalloc may fails, pdata_attr might be null and will cause
> > illegal address access later.
> >
> > Signed-off-by: Kang Chen <void0red@gmail.com>
> > ---
> >  drivers/staging/r8188eu/core/rtw_p2p.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/staging/r8188eu/core/rtw_p2p.c b/drivers/staging/r=
8188eu/core/rtw_p2p.c
> > index 93d3c9c43..802e1170a 100644
> > --- a/drivers/staging/r8188eu/core/rtw_p2p.c
> > +++ b/drivers/staging/r8188eu/core/rtw_p2p.c
> > @@ -31,6 +31,8 @@ static u32 go_add_group_info_attr(struct wifidirect_i=
nfo *pwdinfo, u8 *pbuf)
> >       struct sta_priv *pstapriv =3D &padapter->stapriv;
> >
> >       pdata_attr =3D kzalloc(MAX_P2P_IE_LEN, GFP_KERNEL);
> > +     if (!pdata_attr)
> > +             return 0;
>
> Return success here is not a good thing.  We have to fix the caller to
> check for errors.  (Fixing a bug half way just makes it harder to find
> the bug so it makes the situation worse).
>
> regards,
> dan carpenter
>