On Thu, May 28, 2026 at 04:00:53AM -0400, Sean Anderson wrote:
> On 5/28/26 02:18, Dan Carpenter wrote:
> > On Wed, May 27, 2026 at 08:31:59PM -0400, Sean Anderson wrote:
> > > On 5/25/26 03:16, Dan Carpenter wrote:
> > > > If the *ppos is non-zero then simple_write_to_buffer() will not
> > > > initialize the start of the buf[] buffer.  It doesn't really make sense
> > > > to allow non-zero values for *ppos, so check for that at the start and
> > > > return -EINVAL.
> > > 
> > > non-zero ppos seems to be handled properly by simple_write_to_buffer.
> > > 
> > 
> > It's not an overflow bug, it's an uninitialized variable bug.
> > 
> > The simple_write_to_buffer() is designed to handle partial writes so it
> > leaves the first "written" (scare quotes) part of the string as is.  But
> > in this case, we can't handle a partial write and the first part of
> > buf[] is left uninitialized.
> > 
> > https://staticthinking.wordpress.com/2026/05/23/simple_write_to_buffer-is-complicated/
> 
> OK, that's a bit strange. Can you add this to the doc comment? I certainly
> missed it when looking around for appropriate functions.
> 
> And I like the explicit copy_from_user variant better, especially since
> we are setting the nul-terminator anyway.
> 
> > Also this appears to be dead code since fops_zynqmp_dp_pattern is never
> > used.
> 
> It's of course used in zynqmp_dp_bridge_debugfs_init.

Ah, yes.  I just did a git grep and the CREATE_FILE() macro confused me.
But obviously this wouldn't compile if we had an unused local variable.
Duh...

regards,
dan carpenter

Reply via email to