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() but in this case it is simpler to add NULL to the first position since we want to empty the string.
This is a previous step in the path to remove the strcpy() function.
Signed-off-by: Len Baker len.baker@gmx.com --- drivers/staging/fbtft/fbtft-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index 3723269890d5..b8791806cb20 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -1037,7 +1037,7 @@ int fbtft_init_display(struct fbtft_par *par) case -1: i++; /* make debug message */ - strcpy(msg, ""); + msg[0] = 0; j = i + 1; while (par->init_sequence[j] >= 0) { sprintf(str, "0x%02X ", par->init_sequence[j]); -- 2.25.1
On Sun, Jul 18, 2021 at 4:43 PM Len Baker len.baker@gmx.com wrote:
This is a previous step in the path to remove the strcpy() function.
Any document behind this (something to read on the site(s) more or less affiliated with what is going to happen in the kernel) to read background?
...
Strictly speaking it should be '\0'.
On Sun, Jul 18, 2021 at 9:43 PM Andy Shevchenko andy.shevchenko@gmail.com wrote:
"NULL" is a pointer value, "NUL" is the character with value zero.
While this strcpy() is provably safe at compile-time, and will probably be replaced by an assignment to zero by the compiler...
... the real danger is the
strcat(msg, str);
on the next line. Fortunately this whole debug printing block (including the strcpy) can (and should) be rewritten to just use "%*ph".
Gr{oetje,eeting}s,
Geert
Hi,
On Sun, Jul 18, 2021 at 10:42:42PM +0300, Andy Shevchenko wrote:
This is a task of the KSPP (kernel self protection project) [1]
[1] https://github.com/KSPP/linux/issues/88
Ok, understood.
Thanks for the feedback, Len
dri-devel@lists.freedesktop.org