[ 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:

quoted

quoted

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