From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19D7536C581 for ; Mon, 10 Aug 2026 07:05:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786345560; cv=none; b=rIm4wWNgZWzoYMTWzHYuRkNe2zmTx53Szk+tC52twqZSt0R/9ZjIVsz/ylGFxiM9KMmBsZp42bdeLbVhZMpz/hKgitZJEOrLtBTQYDqI8cbWOpY5ZavvIdMapCykD1fDntkxP0xwZ728Eh/A3hHNNpHc9iGaD9aQa4xLVw1qqm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786345560; c=relaxed/simple; bh=KiYTJr6ciY41S0faZ/K7ky6D53SOLmHv6iAAKkbh7HQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KFUjRDHDC8CURrKr6VvDGAgx5ZExfLEhsUunjTD6JTgn5p82HDn3fOkdljxb5hCZ2CKbXxJDsdVF5Tmyu7t9vsHgUhXcj9sYGrhfeaXAPegZXnhJDfR1J6E6mMc6CyFSM+jsobvKv53Icfjf9RBLyXgAv7ooBTR6nxsAjgEoJIg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=S+9F4e/p; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=XKy8TVbR; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="S+9F4e/p"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="XKy8TVbR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786345557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vr3vIYuq7lla3+ZHZmoYb7uvd3kFa0mXYvvwO+akg2g=; b=S+9F4e/p2edaHvBcXha1E2PZHEVEuDPSIQjMxwks7C0x5BlGDksFB5gI7/37AGoLH2M61G IrCIE+hs/1VFhb9r2CUfmbf3++3nQQ2YC6v0ZUT2TX0aBKzZ47URc1f4wHYwslhgQJa+EO j1WD93Q2LkHpLS4HCHaeBY7N7Lwlfus= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-676-MpGCbFexMcGEf_8b_Xe5KA-1; Mon, 10 Aug 2026 03:05:51 -0400 X-MC-Unique: MpGCbFexMcGEf_8b_Xe5KA-1 X-Mimecast-MFC-AGG-ID: MpGCbFexMcGEf_8b_Xe5KA_1786345550 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4955ce558d8so15315625e9.3 for ; Mon, 10 Aug 2026 00:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786345550; x=1786950350; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Vr3vIYuq7lla3+ZHZmoYb7uvd3kFa0mXYvvwO+akg2g=; b=XKy8TVbR8+mJ6B8l5YnrSdxuACPKqSIcBBXgZWhy5XOXn/32+mEu8YMeg0fgIxXqiM CV4I79q4zhceEXXpdFJbvNAXdaGHSoQxaMBDNxsm7UDVRqUTXqc9lu1PbcVhSj4ltR9W chb/ken5S6j4N0S33Kze2BrNYCTAB4ELVFlnqPcQ1Q8dFtjJmht3tgCZb7i4WL+sYzMk LkstPJYzlYk7n9/Lgya79nZpHAaKt4Cr/9ySM0V0A2GEpHPMFmBLfcwpyjKRp9PXhDi7 7GJJ3w1A1EKQGVs0J3IzCn5ePQRVoZYlrcmTYR/N6q6F3PemR+spvzRjyeAu7p9HiTWP LKNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786345550; x=1786950350; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Vr3vIYuq7lla3+ZHZmoYb7uvd3kFa0mXYvvwO+akg2g=; b=fVWrwC/vIa2ZZVdnFjLWVGYKeWodiWC9wNqE+s7QhGpLsM8gjpFe9rdpu3RcfL0ojt fVYlpC8dj0X/qmSe9hXwVjweX33pS5IvedcnHC0m6Ps0EXNJjl4X90pi2cua+b7uVp0h xHKCuky7Cx2DB29dKK7An3QD4N9QdkasP3LvDHereexdVdnhMI+sTq3UmvdmwmbUMbdU 1o5C00nPxNU9P9s+mcTNaivztewxDzgIkJBiHV5V25KYIctGs5harpefDbnn6k95j6Xd R6lFAkC2fqC+5AKIsMo29j1DAKovmf58MWgZf7DtNGoHkNVf/JAGThrEZY53qkTPb+cK ILfQ== X-Forwarded-Encrypted: i=1; AHgh+RpPVXedS3AOXI8veInek8UE5X4YnofIlXnqCMA7KB1RXhohhD9m7qxAYraq0YeHUSrA1QRBOWNAVDpakxw=@vger.kernel.org X-Gm-Message-State: AOJu0YyNWMUVmTaoWHVV98GhdvJheGgs0tprtVdXpi1G9Nk8g0o1q0MS IkM3b2yLSplT5Y6SgHIiSsFAU7zNh3yBh28fcT/m88OE/zGGL6vTfiafXDYYt/qGOt6GkTwxPpp KvQY4470cGtWxelbAp9Ju7KTI41yJoJgAXyB0gMhWVwPzO5YvCaDRY6AgqfZYiyfoIdQ8lFlXhg == X-Gm-Gg: AR+sD13r7XjbosI9G/NKAYJq1ETNIa01t3WdrWEVEOn5A8nYU8A2Wnt9v2vBCn8pmDl hVoyTiBCR7LSqw86a9GdSaYWklD6lYXr5qFEAnxH2X29zWlUkUxjZm5W5kdExe1l+GLA/57SnmF dJd8Q0soIhdRQxokiL1bZHXyoX5M9hTSAWmWZYaTnoq7P8JPybdW6DTBriKOFi+WEPeS64QZVL+ hDd/3M/rAnNFe+TlusI0T+YP6yE3VM4MCzdeGiWbA5ojr3q/dvdmX6IOGHAZJsTlc6KC5KXxNLz 8829bYr6Wheivn3UNojOO3q9aFP01d4gJ7ma1nU0j00C9nful8uos00g/gH6CaRLi11Rzhpfdad RX7crO1/RqVYqXHJA/UyTWQ== X-Received: by 2002:a05:600c:3b88:b0:499:52ab:a50c with SMTP id 5b1f17b1804b1-4996194e24bmr260254915e9.1.1786345550221; Mon, 10 Aug 2026 00:05:50 -0700 (PDT) X-Received: by 2002:a05:600c:3b88:b0:499:52ab:a50c with SMTP id 5b1f17b1804b1-4996194e24bmr260254165e9.1.1786345549684; Mon, 10 Aug 2026 00:05:49 -0700 (PDT) Received: from redhat.com (IGLD-80-230-39-98.inter.net.il. [80.230.39.98]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995420bd1csm395892805e9.3.2026.08.10.00.05.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 00:05:49 -0700 (PDT) Date: Mon, 10 Aug 2026 03:05:46 -0400 From: "Michael S. Tsirkin" To: Dmitry Torokhov Cc: Hari Mishal , Amit Shah , Arnd Bergmann , Greg Kroah-Hartman , Gerd Hoffmann , Jason Wang , David Hildenbrand , Henrik Rydberg , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org Subject: Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count Message-ID: <20260810030400-mutt-send-email-mst@kernel.org> References: <20260715142337.22811-1-harimishal1@gmail.com> <20260715142337.22811-3-harimishal1@gmail.com> <20260715115018-mutt-send-email-mst@kernel.org> <20260715120911-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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