On Thu, Jul 16, 2026 at 10:33:04AM -0700, Dmitry Torokhov wrote: > [ 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.
This last part isn't always true, while hypervisors are generally more trusted than a random usb device, the level of trust isn't always higher level than the VM. Still if it's a theoretical misconfiguration that leads to nothing bad, not worth special casing it. > > Thanks. > > > > -- > Dmitry
