[ Just realized that CC was dropped in the email I was replying to, so restoring and resending... ]
On Thu, Jul 16, 2026 at 10:28:36AM -0700, Dmitry Torokhov wrote: > On Thu, Jul 16, 2026 at 12:34:57PM +0200, Hari Mishal wrote: > > > What is the failure mode if we keep the ABS_MT_SLOT capability? Does the > > > kernel crash? And if this can cause crash then we should fix > > > input_mt_init_slots() to reject requests for 0 slots with -EINVAL. > > > > > > > No, it doesn't crash. I think every place in the input core that touches > > dev->mt guards against it being NULL: input_handle_abs_event() and > > the mt_slots check in input.c, and evdev's EVIOCGMTSLOTS ioctl > > handler all explicitly check for NULL and degrade cleanly instead of > > dereferencing. From my understanding, the worst case is what the > > original commit message already covers: the device advertises > > multitouch support it can't back. > > So what? I still do not see the problem. Let's say I have a device that > properly supports multitouch and has slots, but then never sends any > events because firmware is buggy. How would that affect anything? > > If there is no crash that I would leave the driver alone. > > And we need to remember that we are dealing with a hypervisor here that > normally had higher level of trust than the VM. If it messes up we do > not have to clean up after it. This scenario is different from user > attaching a malicious USB device to their system and getting owned. > > Thanks. > -- Dmitry
