* [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
@ 2025-04-22 18:56 Andy Shevchenko
2025-04-28 23:30 ` Dmitry Torokhov
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2025-04-22 18:56 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel
Cc: Pali Rohár, Andy Shevchenko
When creating a physical device name in the driver the snprintf() takes
an up to 32 characters argument along with the additional 8 characters
and tries to pack this into 32 bytes array. GCC complains about that
when build with `make W=1`:
drivers/input/mouse/alps.c:1411:9: note: ‘snprintf’ output between 8 and 39 bytes into a destination of size 32
1411 | snprintf(priv->phys3, sizeof(priv->phys3), "%s/%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1412 | psmouse->ps2dev.serio->phys,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1413 | (priv->dev2 ? "input2" : "input1"));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/mouse/alps.c:3106:17: note: ‘snprintf’ output between 8 and 39 bytes into a destination of size 32
3106 | snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3107 | psmouse->ps2dev.serio->phys);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix these by checking for the potential overflow.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/input/mouse/alps.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 0bd7b09b0aa3..e76dcb19fa72 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -1401,6 +1401,16 @@ static int alps_do_register_bare_ps2_mouse(struct alps_data *priv)
struct psmouse *psmouse = priv->psmouse;
struct input_dev *dev3;
int error;
+ int n;
+
+ n = snprintf(priv->phys3, sizeof(priv->phys3), "%s/%s",
+ psmouse->ps2dev.serio->phys,
+ priv->dev2 ? "input2" : "input1");
+ if (n >= sizeof(priv->phys3)) {
+ psmouse_err(psmouse,
+ "failed to prepare path to the secondary device\n");
+ return -E2BIG;
+ }
dev3 = input_allocate_device();
if (!dev3) {
@@ -1408,9 +1418,6 @@ static int alps_do_register_bare_ps2_mouse(struct alps_data *priv)
return -ENOMEM;
}
- snprintf(priv->phys3, sizeof(priv->phys3), "%s/%s",
- psmouse->ps2dev.serio->phys,
- (priv->dev2 ? "input2" : "input1"));
dev3->phys = priv->phys3;
/*
@@ -3094,6 +3101,16 @@ int alps_init(struct psmouse *psmouse)
if (priv->flags & ALPS_DUALPOINT) {
struct input_dev *dev2;
+ int n;
+
+ n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
+ psmouse->ps2dev.serio->phys);
+ if (n >= sizeof(priv->phys2)) {
+ psmouse_err(psmouse,
+ "failed to prepare path to the trackstick device\n");
+ error = -E2BIG;
+ goto init_fail;
+ }
dev2 = input_allocate_device();
if (!dev2) {
@@ -3103,8 +3120,6 @@ int alps_init(struct psmouse *psmouse)
goto init_fail;
}
- snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
- psmouse->ps2dev.serio->phys);
dev2->phys = priv->phys2;
/*
--
2.47.2
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
2025-04-22 18:56 [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer Andy Shevchenko
@ 2025-04-28 23:30 ` Dmitry Torokhov
2025-04-29 5:01 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2025-04-28 23:30 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-input, linux-kernel, Pali Rohár
Hi Andy,
On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
> @@ -3094,6 +3101,16 @@ int alps_init(struct psmouse *psmouse)
>
> if (priv->flags & ALPS_DUALPOINT) {
> struct input_dev *dev2;
> + int n;
> +
> + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> + psmouse->ps2dev.serio->phys);
> + if (n >= sizeof(priv->phys2)) {
> + psmouse_err(psmouse,
> + "failed to prepare path to the trackstick device\n");
> + error = -E2BIG;
> + goto init_fail;
So you just broke touchpad of some poor guy who had it working just fine
for many years. For maximum impact you should add BUG() or panic()
here.
In all seriousness, it is OK to have truncated phys, rarely anyone looks
at it and if we get a report of it being truncated then we can consider
addressing the size (or we can decide to live with it truncated).
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
2025-04-28 23:30 ` Dmitry Torokhov
@ 2025-04-29 5:01 ` Andy Shevchenko
2025-05-02 13:52 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2025-04-29 5:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andy Shevchenko, linux-input, linux-kernel, Pali Rohár
Mon, Apr 28, 2025 at 04:30:13PM -0700, Dmitry Torokhov kirjoitti:
> On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
> > @@ -3094,6 +3101,16 @@ int alps_init(struct psmouse *psmouse)
> >
> > if (priv->flags & ALPS_DUALPOINT) {
> > struct input_dev *dev2;
> > + int n;
> > +
> > + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> > + psmouse->ps2dev.serio->phys);
> > + if (n >= sizeof(priv->phys2)) {
> > + psmouse_err(psmouse,
> > + "failed to prepare path to the trackstick device\n");
> > + error = -E2BIG;
> > + goto init_fail;
>
> So you just broke touchpad of some poor guy who had it working just fine
> for many years. For maximum impact you should add BUG() or panic()
> here.
Ha-ha. You know that your speculation most likely so far from the truth.
> In all seriousness, it is OK to have truncated phys, rarely anyone looks
> at it and if we get a report of it being truncated then we can consider
> addressing the size (or we can decide to live with it truncated).
In all seriousness, while I agree on the statement, the 4 drivers in Input
subsystem break the build. It's the biggest obstacle now to enable WERROR=y,
which is default, builds on `make W=1`. So, I already gave you chance to fix,
instead I hear nothing back for a months (to be precise 2 months and a day
passed from my first attempt that you didn't like), the problem still exists.
Please, address this the way you like.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
2025-04-29 5:01 ` Andy Shevchenko
@ 2025-05-02 13:52 ` Andy Shevchenko
2025-05-06 5:34 ` Dmitry Torokhov
0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2025-05-02 13:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Pali Rohár
On Tue, Apr 29, 2025 at 08:01:10AM +0300, Andy Shevchenko wrote:
> Mon, Apr 28, 2025 at 04:30:13PM -0700, Dmitry Torokhov kirjoitti:
> > On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
...
> > > + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> > > + psmouse->ps2dev.serio->phys);
> > > + if (n >= sizeof(priv->phys2)) {
> > > + psmouse_err(psmouse,
> > > + "failed to prepare path to the trackstick device\n");
> > > + error = -E2BIG;
> > > + goto init_fail;
> >
> > So you just broke touchpad of some poor guy who had it working just fine
> > for many years. For maximum impact you should add BUG() or panic()
> > here.
>
> Ha-ha. You know that your speculation most likely so far from the truth.
And actually what you are telling about is not true at all. If the device was
working it means that the file node name is not cut, and hence this patch won't
anyhow change this behaviour. Otherwise, provide an example which can fail this
and still be working in the user space.
> > In all seriousness, it is OK to have truncated phys, rarely anyone looks
> > at it and if we get a report of it being truncated then we can consider
> > addressing the size (or we can decide to live with it truncated).
>
> In all seriousness, while I agree on the statement, the 4 drivers in Input
> subsystem break the build. It's the biggest obstacle now to enable WERROR=y,
> which is default, builds on `make W=1`. So, I already gave you chance to fix,
> instead I hear nothing back for a months (to be precise 2 months and a day
> passed from my first attempt that you didn't like), the problem still exists.
> Please, address this the way you like.
For the reference, the first approach:
https://lore.kernel.org/r/20250228121147.242115-1-andriy.shevchenko@linux.intel.com
where I also asked about this one, ano got no answer.
I really don't want to try anything new as it seems a big pushback to whatever
I propose. So, please consider fixing the issues rather sooner. I will be more
than happy to test.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
2025-05-02 13:52 ` Andy Shevchenko
@ 2025-05-06 5:34 ` Dmitry Torokhov
2025-05-07 13:49 ` Andy Shevchenko
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2025-05-06 5:34 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-input, linux-kernel, Pali Rohár
On Fri, May 02, 2025 at 04:52:51PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 29, 2025 at 08:01:10AM +0300, Andy Shevchenko wrote:
> > Mon, Apr 28, 2025 at 04:30:13PM -0700, Dmitry Torokhov kirjoitti:
> > > On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
>
> ...
>
> > > > + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> > > > + psmouse->ps2dev.serio->phys);
> > > > + if (n >= sizeof(priv->phys2)) {
> > > > + psmouse_err(psmouse,
> > > > + "failed to prepare path to the trackstick device\n");
> > > > + error = -E2BIG;
> > > > + goto init_fail;
> > >
> > > So you just broke touchpad of some poor guy who had it working just fine
> > > for many years. For maximum impact you should add BUG() or panic()
> > > here.
> >
> > Ha-ha. You know that your speculation most likely so far from the truth.
If your code is not a noop that is precisely what happened.
>
> And actually what you are telling about is not true at all. If the device was
> working it means that the file node name is not cut, and hence this patch won't
> anyhow change this behaviour. Otherwise, provide an example which can fail this
> and still be working in the user space.
"phys" is not a name of a device node. It is a string available via
/proc/bus/input/devices, sysfs /sys/class/input/input<N>/phys and also
EVIOCGPHYS ioctl. A driver is free to not set it at all and everything
will be working fine.
Actually, input devices themselves to not have device nodes, it is evdev
interface that provides /dev/input/event<N>.
>
> > > In all seriousness, it is OK to have truncated phys, rarely anyone looks
> > > at it and if we get a report of it being truncated then we can consider
> > > addressing the size (or we can decide to live with it truncated).
> >
> > In all seriousness, while I agree on the statement, the 4 drivers in Input
> > subsystem break the build. It's the biggest obstacle now to enable WERROR=y,
> > which is default, builds on `make W=1`. So, I already gave you chance to fix,
> > instead I hear nothing back for a months (to be precise 2 months and a day
> > passed from my first attempt that you didn't like), the problem still exists.
> > Please, address this the way you like.
>
> For the reference, the first approach:
> https://lore.kernel.org/r/20250228121147.242115-1-andriy.shevchenko@linux.intel.com
> where I also asked about this one, ano got no answer.
Sorry I was busy with other projects.
>
> I really don't want to try anything new as it seems a big pushback to whatever
> I propose. So, please consider fixing the issues rather sooner. I will be more
> than happy to test.
Have you considered that this warning is bogus and it should be disabled
instead? Or maybe GCC should see if there are followup writes to the
same buffer before emitting the warning?
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer
2025-05-06 5:34 ` Dmitry Torokhov
@ 2025-05-07 13:49 ` Andy Shevchenko
0 siblings, 0 replies; 6+ messages in thread
From: Andy Shevchenko @ 2025-05-07 13:49 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Pali Rohár
On Mon, May 05, 2025 at 10:34:56PM -0700, Dmitry Torokhov wrote:
> On Fri, May 02, 2025 at 04:52:51PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 29, 2025 at 08:01:10AM +0300, Andy Shevchenko wrote:
> > > Mon, Apr 28, 2025 at 04:30:13PM -0700, Dmitry Torokhov kirjoitti:
> > > > On Tue, Apr 22, 2025 at 09:56:45PM +0300, Andy Shevchenko wrote:
...
> > > > > + n = snprintf(priv->phys2, sizeof(priv->phys2), "%s/input1",
> > > > > + psmouse->ps2dev.serio->phys);
> > > > > + if (n >= sizeof(priv->phys2)) {
> > > > > + psmouse_err(psmouse,
> > > > > + "failed to prepare path to the trackstick device\n");
> > > > > + error = -E2BIG;
> > > > > + goto init_fail;
> > > >
> > > > So you just broke touchpad of some poor guy who had it working just fine
> > > > for many years. For maximum impact you should add BUG() or panic()
> > > > here.
> > >
> > > Ha-ha. You know that your speculation most likely so far from the truth.
>
> If your code is not a noop that is precisely what happened.
>
> > And actually what you are telling about is not true at all. If the device was
> > working it means that the file node name is not cut, and hence this patch won't
> > anyhow change this behaviour. Otherwise, provide an example which can fail this
> > and still be working in the user space.
>
> "phys" is not a name of a device node. It is a string available via
> /proc/bus/input/devices, sysfs /sys/class/input/input<N>/phys and also
> EVIOCGPHYS ioctl. A driver is free to not set it at all and everything
> will be working fine.
Okay, this is then indeed a problematic in the cases when strings are shorten
than supposed to be.
> Actually, input devices themselves to not have device nodes, it is evdev
> interface that provides /dev/input/event<N>.
>
> > > > In all seriousness, it is OK to have truncated phys, rarely anyone looks
> > > > at it and if we get a report of it being truncated then we can consider
> > > > addressing the size (or we can decide to live with it truncated).
> > >
> > > In all seriousness, while I agree on the statement, the 4 drivers in Input
> > > subsystem break the build. It's the biggest obstacle now to enable WERROR=y,
> > > which is default, builds on `make W=1`. So, I already gave you chance to fix,
> > > instead I hear nothing back for a months (to be precise 2 months and a day
> > > passed from my first attempt that you didn't like), the problem still exists.
> > > Please, address this the way you like.
> >
> > For the reference, the first approach:
> > https://lore.kernel.org/r/20250228121147.242115-1-andriy.shevchenko@linux.intel.com
> > where I also asked about this one, ano got no answer.
>
> Sorry I was busy with other projects.
>
> > I really don't want to try anything new as it seems a big pushback to whatever
> > I propose. So, please consider fixing the issues rather sooner. I will be more
> > than happy to test.
>
> Have you considered that this warning is bogus and it should be disabled
> instead? Or maybe GCC should see if there are followup writes to the
> same buffer before emitting the warning?
I considered this warning as a problem that prevents me compiling the code.
Since there are only few issues over the kernel left with some maintainers
who are definitely busy, I consider the disabling warning wouldn't make it
better. And if so, this should be send not by me, I have no good arguments
against it. Perhaps you have?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-05-07 13:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-22 18:56 [PATCH v1 1/1] Input: ALPS - bail out when device path can't fit buffer Andy Shevchenko
2025-04-28 23:30 ` Dmitry Torokhov
2025-04-29 5:01 ` Andy Shevchenko
2025-05-02 13:52 ` Andy Shevchenko
2025-05-06 5:34 ` Dmitry Torokhov
2025-05-07 13:49 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).