From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CA5443991D for ; Thu, 16 Jul 2026 17:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784223193; cv=none; b=KsD0MjLN0WigfOKFp6bRWFr4GBSVRXheuqHtgqtTQ/muvvU8iiZnmukhUbdTHro6FudscUEMc+e4u5TiJJ9mVIx782Ku1L8b/n/mezVDby2Y2psK2Na0MbTaTsclKMJNuUiJvyZkzFTCVyYLrCTYxtBccL9N2f90zuuDH429tgg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784223193; c=relaxed/simple; bh=14Cq1umL0Y6RBF2SkI1K9PaiHWJyUXEl/l/NTRstlkQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MNA0LJRahmekR8RGuhBsh3vFq07nr8MOWNMHDfuRQYHITuL4akMlYaYBlmFY2oLIqs5jB1rHJsjZKE1X1e6Vdnj3v2K1S4ESnvyPr8rQEvF77jeiWPSAlvVMUISpwhHHTzAJ7gVovYSVSBPvaxt+fVkbO5PK2dAfgwPgd01XKCk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hiz2TXaI; arc=none smtp.client-ip=209.85.210.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hiz2TXaI" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-8487214ad2bso5019339b3a.1 for ; Thu, 16 Jul 2026 10:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784223188; x=1784827988; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-description:content-type :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=xrxnv9tUHFGYCrkcPFQu3jVeHPBv/ZazS8X/HiiUaCM=; b=hiz2TXaIpXBXcgGSa3SksrvE1HkTf7NNmBkDfyY9m64q008ZMt84dDI0QRqzFx9lm0 B4fizowr6GfTvY4SIgtV40fUJG0QO0YuMS2+efsthg3EBZCG5YnBYBGKMhc5QX1fdwhj KUgUU2z0hsjceLKl9TyenmyPrK+/7T2rNfOV27/d/4UZ/0+jf8z+1vhiAu82Qpjj9wjn G5cTyRoNDzTcIfDpvmJipKCfW2xJ6L8d1e5v7ywLBITJ12YuacPtFhYMFY/Eet3mMAVO baX/YeiWrG4epEXBIEGjeKQCc06TxXaor7oZQQx8MLaR+ntKqGlqHNRLfUHl/dCy9IHw SU1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784223188; x=1784827988; h=in-reply-to:content-disposition:content-description: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=xrxnv9tUHFGYCrkcPFQu3jVeHPBv/ZazS8X/HiiUaCM=; b=VPZKWqYwNSwfiil2+X7KwXvTqbybeV/VEYU3Cq6udFannFDxlDJoNak06YuVM60aoB KOV1t1OvxojFHKp3SuZ41bkMzRa3TCa/qaL6IQBvpSGV4wHcqitBU6A5G9PU7OA5nLkC MjsGXygY3trAsV5Ea9/HzM1y/A01cKzpr6Cs/ll9nT+m+hxuH5j7iysMflLWYyRzX9Me sgnl23PJ5rR6D32P2/tawpIHrPsaEzU/J1uovWZWwmCa1X+QU7UBWdfqZsFab2XLt5Fn Fw8FwuJtmRymVTKsw/TAvCH1WyIrzprWLo86nEciuD0RTbN2HJDW7fk4B4R0Ej0FLBJI PepA== X-Forwarded-Encrypted: i=1; AHgh+Rond2xD33xcWxIGVJXbvpazjUT9VTTrxa9vBVovVRocdYqoLtbZ6U2wzfFmB17Lj87yaIHCy3jp73okMyo=@vger.kernel.org X-Gm-Message-State: AOJu0YxN0j1SVXXKlIzVgOaqQOIOigdSLcnrFaGwkMca7Dgh819GYmWB jbnD7HVfiAT9+tixMrtCSKZsRbq4JsN7FDH+mxv6EfE+yfGmWRWDNoCz X-Gm-Gg: AfdE7ckTByk/K+6MlFGsfC6YEkUd7nMbyQAwdVocTPLgkzkL0UCr2T67yISZ7mIHJpZ TjsV6/648uTEk+88JJAe9uWqXbrkK7BeGfpyC5F0EB9lRTiSVWvWr6lyvELzzQEhBmZBwrITBeP 80MB8i1mJ+vJFLFmiMOA+RLw6d8fWcLLPelX1d/rTZ2jtZY5L+UkltizhfHefcveZyqpwriPkyR t2CUWmcSvilDd8pzWGOvMUPjUJfk1HwaRNpA/slMGxXX+X9mJn9cjCxQFyA0XDfFPXQQ3xaniSY +3HCyMWy/8R8l5cExdKAKMWpIg+E+rt2QRJdENebK+fUc0L9RXHkbdKZ6KL2M8UyOD1KhS6ohht WDO/m1xsSKMEApMdVo/UYDtAAAXkM3H42pulItNVOVxl2BTCp/FBaseepTB+iDdJLp1O4pfWkpA G1ii+43dafistDenG6621E0uHHBUJR5l8eyhlqwRu60B8= X-Received: by 2002:a05:6a20:244f:b0:3c3:9557:3b56 with SMTP id adf61e73a8af0-3c3a5e12181mr84522637.72.1784223188091; Thu, 16 Jul 2026 10:33:08 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:38ea:b937:53f6:928c]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13cd4284a92sm10258037c88.4.2026.07.16.10.33.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2026 10:33:07 -0700 (PDT) Date: Thu, 16 Jul 2026 10:33:04 -0700 From: Dmitry Torokhov To: Hari Mishal Cc: "Michael S. Tsirkin" , Amit Shah , Arnd Bergmann , Greg Kroah-Hartman , Gerd Hoffmann , Jason Wang , David Hildenbrand , Henrik Rydberg , Xuan Zhuo , Eugenio =?utf-8?B?UMOpcmV6?= , 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: 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-Description: avid@kernel.org>, Henrik Rydberg =?utf-8?Q?=3Crydberg?= =?utf-8?Q?=40bitmath=2Eorg=3E=2C__Xuan_Zhuo_=3Cxuanzhuo=40linux=2Ealibaba?= =?utf-8?B?LmNvbT4sIEV1Z2VuaW8gUMOpcmV6?= , Content-Disposition: inline In-Reply-To: [ 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