[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210807174839.GF2688@titan>
Date: Sat, 7 Aug 2021 19:48:39 +0200
From: Len Baker <len.baker@....com>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Len Baker <len.baker@....com>, Kees Cook <keescook@...omium.org>,
Andy Gross <agross@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
Santosh Shilimkar <ssantosh@...nel.org>,
David Laight <David.Laight@...lab.com>,
Robin Murphy <robin.murphy@....com>,
linux-hardening@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3] drivers/soc: Remove all strcpy() uses
Hi,
On Wed, Aug 04, 2021 at 05:23:54PM -0500, Bjorn Andersson wrote:
> On Sun 01 Aug 08:19 CDT 2021, Len Baker wrote:
>
> > strcpy() performs no bounds checking on the destination buffer. This
> > could result in linear overflows beyond the end of the buffer, leading
> > to all kinds of misbehaviors. The safe replacement is strscpy().
> >
>
> While this is true, are any of these uses of strcpy affected by its
> shortcomings?
No, this patch is only an effort to clean up the proliferation of str*()
functions in the kernel.
> > Moreover, when the size of the destination buffer cannot be obtained
> > using "sizeof", use the memcpy function instead of strscpy.
> >
>
> This is not why you're using memcpy, you're using it because you _know_
> how many bytes should be copied - because you just did a strlen() and
> allocated that amount of space.
Understood, I will change the commit message.
>
> > [...]
> > /* Prepare req message */
> > - strcpy(req.service_path, pds->service_path);
> > + strscpy(req.service_path, pds->service_path,
> > + sizeof(req.service_path));
>
> There's no need to break this line.
Ok, thanks.
Regards,
Len
Powered by blists - more mailing lists