[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYMpLEM7ZfXglGbc@stanley.mountain>
Date: Wed, 4 Feb 2026 14:10:36 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Artem Lytkin <iprintercanon@...il.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Teddy Wang <teddy.wang@...iconmotion.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-fbdev@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] staging: sm750fb: add bounds checking to option
parsing in lynxfb_setup()
On Wed, Feb 04, 2026 at 10:15:33AM +0000, Artem Lytkin wrote:
> Replace strcat() with memcpy() and add explicit bounds checking on the
> remaining buffer space before each copy. The original code lacked any
> validation that the write position stays within the allocated buffer.
>
This implies that there is a buffer overflow. It's important to review
this sort of thing and add a Fixes tag if the buffer overflow is real.
In this case the code works ok as-is. My main problem with the
original code is what you explained in the v1 commit, the strcat() was
just doing a memcpy(). It wasn't concatenating two strings.
Just resend the v1 patch with the following commit message:
As part of kernel hardening, I am auditing calls to strcat(). This
code works but it is a bit ugly.
This function takes a string "options" and allocates "g_settings"
which is large enough to hold a copy of "options". It copies all the
options from "options" to "g_settings" except "noaccel", "nomtrr" and
"dual". The new buffer is large enough to fit all the options so
there is no buffer overflow in using strcat() here.
However, using strcat() is misleading because "tmp" always points
to the next unused character in the "g_settings" buffer and it's
always the NUL character. Use memcpy() instead to make the code
easier to read. This also removes an instance of strcat() which
is a #NiceBonus.
regards,
dan carpenter
Powered by blists - more mailing lists