[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-input
Subject:    Re: [PATCH] input/vmmouse: Fix device name copies
From:       Dmitry Torokhov <dmitry.torokhov () gmail ! com>
Date:       2023-12-08 23:45:02
Message-ID: ZXOp5y4F2aoRq2UT () google ! com
[Download RAW message or body]

On Sun, Dec 03, 2023 at 09:14:49PM +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 03 December 2023 20:51
> > On Sun, Dec 3, 2023, at 19:41, Dmitry Torokhov wrote:
> > > On Mon, Nov 27, 2023 at 03:42:06PM -0500, Zack Rusin wrote:
> > > > From: Zack Rusin <zackr@vmware.com>
> > > > 
> > > > Make sure vmmouse_data::phys can hold serio::phys (which is 32 bytes)
> > > > plus an extra string, extend it to 64.
> > > > 
> > > > Fixes gcc13 warnings:
> > > > drivers/input/mouse/vmmouse.c: In function ‘vmmouse_init':
> > > > drivers/input/mouse/vmmouse.c:455:53: warning: ‘/input1' directive output \
> > > > may be truncated writing
> > 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
> > > > 455 |         snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
> > > > > ^~~~~~~
> > > > drivers/input/mouse/vmmouse.c:455:9: note: ‘snprintf' output between 8 and \
> > > > 39 bytes into a
> > destination of size 32
> > > > 455 |         snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
> > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > 456 |                  psmouse->ps2dev.serio->phys);
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 
> > > This simply wastes 32 bytes. It is perfectly fine to truncate phys
> > > (which does not happen in real life).
> > > 
> > > -Wformat-truncation is disabled in normal builds, folks should stop
> > > using it with W=1 as well.
> > 
> > It does find real bugs, and we are fairly close to being able
> > to enable it by default once the remaining warnings are all
> > fixed.
> > 
> > It also doesn't waste any memory

... at this time ...

> > in this specific case since
> > vmmouse_data is currently at 168 bytes, which gets rounded
> > up to either 192 or 256 bytes anyway. I'd suggest using
> > the minimum size that is large enough though, in this case
> > 39 bytes for the string I guess.

This assumes we never change how our allocators work to provide better
memory packing.

> 
> That rather depends on whether any of the earlier char[] lengths
> have been rounded up to a 'nice' value.
> 
> I'd also have thought that dangerous overflows would come from
> unbounded %s formats, not fixed size strings or integers that are
> always small.
> 
> There really ought to be a sane method of telling gcc not to bleat
> about snprintf() potentially overflowing the target.

Yes, that would be my preference before we enable this warning globally.

Thanks.

-- 
Dmitry


[prev in list] [next in list] [prev in thread] [next in thread]