Re: [PATCH] Input: try trimming too long modalias strings

Jason Andryuk
2024-06-13T01:22:59Z

On Wed, Jun 12, 2024 at 8:17 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, May 27, 2024 at 03:55:57PM -0400, Jason Andryuk wrote:
> > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >
> > commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream.
> >
> > If an input device declares too many capability bits then modalias
> > string for such device may become too long and not fit into uevent
> > buffer, resulting in failure of sending said uevent. This, in turn,
> > may prevent userspace from recognizing existence of such devices.
> >
> > This is typically not a concern for real hardware devices as they have
> > limited number of keys, but happen with synthetic devices such as
> > ones created by xen-kbdfront driver, which creates devices as being
> > capable of delivering all possible keys, since it doesn't know what
> > keys the backend may produce.
> >
> > To deal with such devices input core will attempt to trim key data,
> > in the hope that the rest of modalias string will fit in the given
> > buffer. When trimming key data it will indicate that it is not
> > complete by placing "+," sign, resulting in conversions like this:
> >
> > old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174,
> > new: k71,72,73,74,78,7A,7B,7C,+,
> >
> > This should allow existing udev rules continue to work with existing
> > devices, and will also allow writing more complex rules that would
> > recognize trimmed modalias and check input device characteristics by
> > other means (for example by parsing KEY= data in uevent or parsing
> > input device sysfs attributes).
> >
> > Note that the driver core may try adding more uevent environment
> > variables once input core is done adding its own, so when forming
> > modalias we can not use the entire available buffer, so we reduce
> > it by somewhat an arbitrary amount (96 bytes).
> >
> > Reported-by: Jason Andryuk <jandryuk@gmail.com>
> > Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
> > Tested-by: Jason Andryuk <jandryuk@gmail.com>
> > Link: https://lore.kernel.org/r/ZjAWMQCJdrxZkvkB@google.com
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > [ Apply to linux-6.1.y ]
> > Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> > ---
> > Patch did not automatically apply to 6.1.y because
> > input_print_modalias_parts() does not have const on *id.
> >
> > Tested on 6.1. Seems to also apply and build on 5.4 and 4.19.
>
> How was this tested?

I built a kernel for 6.1.92 + this patch and booted a VM with it.
Inside, I used udevadm and looked at the sysfs entries for
xen-kbdfront.ko.

For 5.4 and 4.19, I just built the module with `make
drivers/input/misc/xen-kbdfront.ko`. I see now that misses building
the actual change. Sorry about that.

> It blows up the build on all branches, 6.1 and older kernels with a ton
> of errors like:
> drivers/input/input.c: In function ‘input_print_modalias_parts’:
> drivers/input/input.c:1397:40: error: passing argument 4 of ‘input_print_modalias_bits’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
> 1397 | 'e', id->evbit, 0, EV_MAX);
> | ~~^~~~~~~

Re-building, I see these as warnings. I don't have -Werror, so they
were non-fatal, and I missed when in the scroll of the full kernel
build.

Sorry about this. I'm preparing new patches.

Regards,
Jason