linux-kernel - Re: [PATCH v1 0/4] Input: Increase size of phys in the drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z-PNiLByle1-9dib@smile.fi.intel.com>
Date: Wed, 26 Mar 2025 11:48:56 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pali Rohár <pali@...nel.org>
Subject: Re: [PATCH v1 0/4] Input: Increase size of phys in the drivers

On Wed, Mar 05, 2025 at 12:06:25PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 04, 2025 at 11:18:52PM -0800, Dmitry Torokhov wrote:
> > On Tue, Mar 04, 2025 at 02:14:12PM +0200, Andy Shevchenko wrote:
> > > On Fri, Feb 28, 2025 at 02:07:43PM +0200, Andy Shevchenko wrote:
> > > > The drivers are using local member of 32 bytes to hold up to 40 (one-byte)
> > > > characters. GCC complains on that. This series fixes the issue in the affected
> > > > input drivers. Note, this is currently the biggest part of the warnings that
> > > > are being treated as errors with the default configurations on x86. With this
> > > > being applied we become quite close to enable CONFIG_WERROR=y (which is default
> > > > and basically reverted) in CIs. Clang, OTOH, has currently no issues with that.
> > > 
> > > Would be nice to have a comment on this rather sooner as this impacts
> > > the compilation by `make W=1` with WERROR=y (which is default).
> > 
> > I do not like the change.
> 
> Independently on your opinion in this case GCC is correct.
> We are trying to squeeze up to 40 bytes into 32-byte storage.
> I.o.w. GCC can't prove that and reader of the code can't prove
> that either.
> 
> > There are no bugs, only GCC being paranoid.
> 
> I'm not so sure. But probably it works because the user space is parsing full
> "inputX" string in the names
> 
> > Are there any other ways to shut it up? In [1] Jeff says that switching
> > to scnprintf() shuts GCC up...
> 
> I do not like this, because it's just a hiding the problem and not solving it.
> At some point GCC may start issuing warning on those cases as well when it
> realizes the above. If you like that solution, please fix in that way. We have
> 4 drivers break the compilation currently.

Actually looking closer, the better fix (and which I'm not against) is to check
for returned value of snprintf() and act accordingly. What do you think?

> > [1] https://lore.kernel.org/r/Z3rIvp0hzS+yzvJA@nixie71
> 
> So, consider this series as a bug report that prevents compilation.
> I would expect somebody to fix this rather sooner than later.

-- 
With Best Regards,
Andy Shevchenko