From nobody Mon Sep 28 06:38:06 2026 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 15DD0346AC0 for ; Tue, 25 Aug 2026 10:31:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653893; cv=none; b=rbZMWwzING94iIzQUDaZGwWWLwjK1HLYQ70IxNhU/4zOBQJ6fQKnfRXUKCXxwxQX0u9dfmqfi6bUm1OGcwuphPVpzCckdWKyMVB+uizgJyBxpghKvRLnkYbGq6pqruCm5TYvIHbCIXIa3JcTfizL3SlujtnYgs/7lrxYautADHw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653893; c=relaxed/simple; bh=nwJF8hkMevEUdXZN81gBgVbQ4KN3f7jxnXKdwBGkXhc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o00e9vBJdEODWhkNRlZrCf50l46QyeLKq03z3VqJjYZacqIASh8p/XLUY1kGT7IPzH58y2IIJlqyXwZpth5rj35ExZ4j/OsbEzS+ixH0v0sAEojZXTknHQAwe/o3hgtgOipS+FqLPpGXCY8GxSv4ZHZXqCYbExUP9WjAFnGWfNg= 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=XSSYYwjD; arc=none smtp.client-ip=209.85.216.42 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="XSSYYwjD" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-38e42560ebcso3658616a91.1 for ; Tue, 25 Aug 2026 03:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787653891; x=1788258691; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Z+eJlGm04XkGO4oIFm6Hc5DTMF8bceRHtuCJpJJ7D9Q=; b=XSSYYwjDgR7th5xtppIbXB5F2ZvylxEblmzi/bDfpMFGayfnojUwv/N1hew/r6pk7h ZwEtcwZhSSUoyibEdxlDclJ//pkwt8sC/iOiVHTzsqIpgxmoHc3l0ODQF4LHiHp45lrd KAczJ1OgBVbln3+x68BVKtiKxiJiOvfcWD6+oCiiX8sVZlwtLI/d6PC8Xgk7FBWahLyM pnXJRO9ErTB0N+2h4r19Cr4pxcLVCJXh0RPNAhtK+x7bXaOYeQJvLa/Fqhxo1+RHmaD2 LYEdTvYqyFBulAShcHmlUubGpbRr/8hUyW7HXKx+Qq8Avnwn9r3KAl+pMm86F9MFDDlp pO0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787653891; x=1788258691; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Z+eJlGm04XkGO4oIFm6Hc5DTMF8bceRHtuCJpJJ7D9Q=; b=SCyyzhof0mWpdBaMAVlYcQdNNNoXs0tSDFYyaV1Fm78UckMs3h7PCkWD5wLid1raeP qrU9qbYaIMox4DuslGbd/66ihkeVgsuP77x6Ve7Hfwm+vi3wuu/hfpwcrg+XvTa4We5X UvO4FhzULgZN1dewN+3+pJhkFqaivCcPUnQ2JSydyGK9GT/lTursW4w7UOL2nQxPupac CZ42Tni/G7ION+Sq5FzN7RKXM/V9ph9wxM5G2KKQhbMwPi/UXTRbbMOuNvLdR4D53a9L i2HLk2dHRLJYGb6bGdk3YLgmZdgqXVTiNnJguE/c4EDbN9ZGPRoy372uDEuHc3qeLOv0 fNgA== X-Forwarded-Encrypted: i=1; AHgh+Rpxyt9LWqMqJEaNMVOFoJ/s730+NowD9o9bE/jqI7yNWs2DUhnhwG+7P8aGSWyN85ywMmXm3X6ugOYSlCA=@vger.kernel.org X-Gm-Message-State: AFuF++nFkePX2OyBi4Gia/6pdvmGvD5l2P1CLtQPXE+BBTZWtXU1Vx8q WrPOG2/zdqkeSYxyH7ST7Gy4ebMadqpMYCBSMRrdziF5l0aNLcHFUiV7 X-Gm-Gg: AR+sD13nL4KCRy8X2lGsQOub3sVmuJv+oetpCg2zARBpqkZBgK2137kzbaIjgqyNbSo rnYCJQHPVYmZf6ZB/XVpQkaUE4MgTdVLTGvCuDbdKDNECETyUREE+KV4TVAE9mNW97SVAUkkXq5 DY0sFklJse/48p7ZU7Uz0pk1PCYyAn2GziEHUZ0AO7I7/Ygr9e1wIh6s12kKBLf/A+7o1nMCwvj RSDC9lHo/E7eFPB8KaQtfR2SXbG4LBSuBs2/uBESxuCHQz8j31BoezFnmAenXS4yiw+lhH9VvFW 4Fayqy7/IB1bKrCc5XuaM1c1plaIRIUX+DuxG9CnXPG0BXzLPSUJhJR33Voarvoidz86CvBMMGp 4UdW19NRX4GDqb1aLC6RRFjeIz5G/eU3h5coQRAAMt02gSjsEBFLdyZlZad66D+xkEGNppeBomE Q0q3L2iwwSgKIf0k3X2KhNLmrJpm3H7PZglBXfKiiB8cFapCqSpT5CvPIxaTE/W3gNqnA5Ujrrc 5xUwUPOU58CnptXYNuyfa2TLrkcqo+WmswV8egLeOk/922Vc5PW4B+HHN6hCTMOx1RTxya6ahJ5 S9TufpyJtiQykDW6EhiLGLGT+uYOb9JFefQ= X-Received: by 2002:a17:90b:184f:b0:395:5f43:4ec4 with SMTP id 98e67ed59e1d1-3964603084fmr11994838a91.0.1787653891187; Tue, 25 Aug 2026 03:31:31 -0700 (PDT) Received: from LAPTOP-UUUVNN1I.localdomain (bb119-74-6-224.singnet.com.sg. [119.74.6.224]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39645d31e8csm3244968a91.9.2026.08.25.03.31.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 03:31:30 -0700 (PDT) From: Wei Jie Law <98lawweijie@gmail.com> To: Dmitry Torokhov Cc: Andrew Duggan , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v4 1/2] Input: synaptics-rmi4 - fix irq[] overrun with 7 interrupt sources Date: Tue, 25 Aug 2026 18:31:22 +0800 Message-ID: <20260825103123.12216-2-98lawweijie@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260825103123.12216-1-98lawweijie@gmail.com> References: <20260825103123.12216-1-98lawweijie@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rmi_read_pdt_entry() takes the interrupt source count straight out of the Page Description Table entry the device supplies: entry->interrupt_source_count =3D buf[4] & RMI_PDT_INT_SOURCE_COUNT_MASK; RMI_PDT_INT_SOURCE_COUNT_MASK is 0x07, so the value can be 7, and rmi_create_function() copies it verbatim into fn->num_of_irqs. But struct rmi_function declares int irq[RMI_FN_MAX_IRQS]; with RMI_FN_MAX_IRQS =3D=3D 6, and both rmi_create_function_irq() and rmi_unregister_function() index that array up to fn->num_of_irqs. A device declaring 7 interrupt sources for a function that has a handler -- F01 always does -- makes the driver write irq[6], which is the storage of the following member, unsigned int irq_pos. The function's position in the interrupt bitmap then holds a Linux virq number, and that value feeds set_bit(fn->irq_pos, ...) in rmi_f11_probe()/rmi_f12_probe() and the irq_dispose_mapping() loop on teardown. UBSAN reports every store in the loop body and the read on the unregister path: UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:183:10 index 6 is out of range for type 'int [6]' Workqueue: events uhid_device_add_worker dump_stack_lvl+0x64/0x80 __ubsan_handle_out_of_bounds+0xc8/0x100 rmi_function_probe+0x1c1/0x210 [rmi_core] UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:186:28 UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:187:35 UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:189:32 UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:191:54 UBSAN: array-index-out-of-bounds in drivers/input/rmi4/rmi_bus.c:282:30 Size the array to match the three bit field that feeds it. Clamping num_of_irqs instead would silently drop an interrupt source a device is allowed to declare, and would desynchronise irq_pos for every function created after it. Reproduced with an emulated RMI4 device that publishes a single F01 PDT entry with interrupt_source_count =3D 7, driven over /dev/uhid and again over dummy_hcd plus raw-gadget, on v6.12.69 and v6.12.105 with CONFIG_UBSAN_BOUNDS=3Dy. No reports after this change, and the same device now probes normally. Fixes: 24d28e4f1271 ("Input: synaptics-rmi4 - convert irq distribution to i= rq_domain") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> --- Changes in v4: - No code change: adds the Assisted-by tags required by Documentation/process/coding-assistants.rst. The diff has been unchanged since v1. drivers/input/rmi4/rmi_bus.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h index 90122df21f74..faf2ebb00d52 100644 --- a/drivers/input/rmi4/rmi_bus.h +++ b/drivers/input/rmi4/rmi_bus.h @@ -12,10 +12,13 @@ struct rmi_device; =20 /* - * The interrupt source count in the function descriptor can represent up = to - * 6 interrupt sources in the normal manner. + * The interrupt source count in the function descriptor is a three bit fi= eld + * (RMI_PDT_INT_SOURCE_COUNT_MASK), so a device can legitimately declare u= p to + * 7 interrupt sources for a single function. irq[] must be able to hold = all + * of them: rmi_create_function_irq() and rmi_unregister_function() both w= alk + * it up to fn->num_of_irqs. */ -#define RMI_FN_MAX_IRQS 6 +#define RMI_FN_MAX_IRQS 7 =20 /** * struct rmi_function - represents the implementation of an RMI4 --=20 2.43.0 From nobody Mon Sep 28 06:38:06 2026 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 BCA45376BCD for ; Tue, 25 Aug 2026 10:31:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653896; cv=none; b=fld8xkWrYJ/3GOpAcE0o+mm7DHp0VsbrPeOfMat58z7aTARu3zZOFXVuXdw54msdTkhd3PEDcGg5Fe6ee7iysLSP7N875l66uGEszGKIwz0r/JINU33C72W/v8AJfWao8EtK+/5xuglySGCRxe6oAJHDLbhol9feBn5CnH4VHzQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653896; c=relaxed/simple; bh=5Qst+fEDdPGOCnJplTLsK3KM3kldbXRhvdfi7PyEUGk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qY+e1MdqFq91j3Srdpmd115fx+JUVN928qHYOPPZmQdEqAOwcQGFJVByTF86zylVC7jbM5Vy6q1d1Dxwx9oNIwziG+2kXpuI49jrs0fCsCxwy395ij6+0WzX9v9q9cYZnR8g/drGvQN19AAxAWv4jrmjX8CPlubL1/TZ8r1sSUo= 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=fbnyx3IE; arc=none smtp.client-ip=209.85.216.45 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="fbnyx3IE" Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-383b4a3755fso5049763a91.3 for ; Tue, 25 Aug 2026 03:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787653894; x=1788258694; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZmdPCfrDSnXxF0kcCEHUxTythGR7yfzC5LrWzS97vcQ=; b=fbnyx3IELw1sQW8IkUSKoebvmTSY4BrCLbud3OkzPHBeLIjRWtQ4QlvQQop7J7GoUk QW336LGz12ZngVa6kYTUK5fRFynzM11g8aI4uPafGKi3WL3B5+vsjogy81DsizxVLDtv QuXLsCf3sUnRnDM59xfeh8AuLq/YkKWymDBTCCA2wX91AScrHB2t+G0ZhcS4S1HhDThI zANLCpuyBnLuaWLWhzUIu8GTdS4w8RVqJvzacR/narx3UwzoQyVZIURfXQsQINLmXcoZ p4zRTJeIz2naMyHq1WrbgpV2XMAXvy0fBE/P1zUUR+/X2+izO4bqER7QGR3sNxgUq+KU RP8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787653894; x=1788258694; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZmdPCfrDSnXxF0kcCEHUxTythGR7yfzC5LrWzS97vcQ=; b=reDwkD+GpWWwjORsZ6oUzKytyRSIokkB4DnTrCBvwhYkPWibweQfHN7c1V2IDvcWAc 6o5Zp4kKHaFdyTBhmrfFqKLbeXg0XYBLbAwslqVmSlJaAO5V3NDQ2FfR4k5E9l4d8Bkz bc4xkM0L5BLrCmftH689vqdVKFpl7RdcXSNwccCtrrZjm5ij0HHQ4J9cf8NGayh7DqR3 5zNgl1IEhr7d2Rd9nqb2H8jk2TrOlKUHxvHC5pc47qczJxhZ2AMF/cgqt+rrHob4ehXP Suuz7nskqOcAdp/SnoHnrX4tDrN1mC2UQGV7h/bYuEX88P4WhfM/KwKvNPOhuOcHPmH4 QjYQ== X-Forwarded-Encrypted: i=1; AHgh+RoLLxHTUQe7PlnZJYDUXChjZdhnc2YzQj5k0s0GypRP9PVQmBf/o8EzOVVPfL0PhfqqDcdPIM8Qxd4OF+0=@vger.kernel.org X-Gm-Message-State: AFuF++khCBQpnmcC7SZNxltl4dVPyaRawU83y27MTR1CjlGctxHGumP/ TC05lBIA4YiHz7dUpiyUZ/9TxuWP7CYy/6cXcEhMt+o7dQI0QvqWGLgl6SazR39iGSc= X-Gm-Gg: AR+sD1280AFlhO36yYf9dKEtijoAUBKzVgBiOrPO+ptq+cyaPUByZJM5gah0Itq5xak N66/UEnEBOUHDrB//NVpf1yQj0qiFRTjHigRMF/IlgNtAmaxALafphAokonXpjqqdY9Bl2lfF1o 5/i2UWtMxrmu2qRMM8hoP2C9vbHXRgMR7NJBZxndOWZU8rogINBH/VaQWDPzTnFLLjr8T+c7oYJ hJ14GMFY3HCgo+mv4oV8cGcveP6OC1MsFy4VLYglbrCrkEQn3/6imHnzRlDmuLvSj+5nZBSL+Hk uBAFO08rLy2uGkPCM3FuK6vllwgw0nhoESBT7LgMefVg10d5r4m4RpMWdWN+bmckv+EK5EIg+nm HvkZrV2+mzp6wWULWmigC/my3Hl/1q8m3kExPwt0GD9QwTsOiiGFulSEHbAcSvEDksQHIBQroEl 4N+bPjFM4uHMnw6bsVG+vkIcjB7W3UOGBJZ9xNrkEF6gMTf5jvRl5vU07OZce2G++aGjYJmF8XO taVdUOuzpRrDtlfqD6EK4uqlfzCPN9KngCIQsr2hDuWj4JMoirsGLkJzMu1SHewbBp44ulh8cxb 1DT4CGV8/XwkYGKzEzmgxz/j X-Received: by 2002:a17:90a:1c17:b0:396:5f7f:52f5 with SMTP id 98e67ed59e1d1-3965f7f5486mr1616456a91.3.1787653893954; Tue, 25 Aug 2026 03:31:33 -0700 (PDT) Received: from LAPTOP-UUUVNN1I.localdomain (bb119-74-6-224.singnet.com.sg. [119.74.6.224]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39645d31e8csm3244968a91.9.2026.08.25.03.31.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 03:31:33 -0700 (PDT) From: Wei Jie Law <98lawweijie@gmail.com> To: Dmitry Torokhov Cc: Andrew Duggan , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v4 2/2] Input: synaptics-rmi4 - reject a PDT that grows between scans Date: Tue, 25 Aug 2026 18:31:23 +0800 Message-ID: <20260825103123.12216-3-98lawweijie@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260825103123.12216-1-98lawweijie@gmail.com> References: <20260825103123.12216-1-98lawweijie@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" rmi_driver_probe() walks the Page Description Table three times, and each walk reads the table back from the device: 1. rmi_initial_reset - issue the reset command in the F01 entry 2. rmi_count_irqs - total the interrupt sources 3. rmi_create_function - create the functions and set their irq bits Scan 2 fixes data->irq_count, data->num_of_irq_regs and the size of every per-function irq_mask[]. Scan 3 then accumulates fn->irq_pos and does for (i =3D 0; i < fn->num_of_irqs; i++) set_bit(fn->irq_pos + i, fn->irq_mask); without checking the result against the count that sized the bitmap. Nothing makes the device answer the third scan the way it answered the second, so a device that reports one function with one interrupt source on scan 2 and a long list of functions on scan 3 walks set_bit() past the end of the flexible array at the tail of every struct rmi_function: BUG: KASAN: slab-out-of-bounds in rmi_create_function+0x560/0x930 [rmi_co= re] Write of size 8 at addr ffff888110c92b58 by task kworker/1:2/129 Workqueue: events uhid_device_add_worker kasan_report+0xc6/0x100 kasan_check_range+0x105/0x1b0 rmi_create_function+0x560/0x930 [rmi_core] rmi_scan_pdt+0x190/0x3f0 [rmi_core] rmi_init_functions+0xb8/0x320 [rmi_core] rmi_driver_probe+0x31e/0xbf0 [rmi_core] one report per corrupted function object. The same unvalidated fn->irq_pos is used again by the set_bit() and irq_create_mapping() in rmi_create_function_irq(). Validate the counts before the function is allocated and fail the probe instead. The check is exact, not conservative: when both scans see the same table, the running interrupt total plus the new function's count is exactly what produced data->irq_count, so it never fires for a device that behaves. Placing the check before rmi_alloc_function() is deliberate. Since commit 58d42ec10b73 ("Input: rmi4 - refactor function allocation and registration") that function has already run device_initialize() and dev_set_name() on fn->dev, so disposing of a rejected function with kfree() would leak the name string and skip kobject cleanup on those trees, while put_device() on the same path broke on the pre-refactor trees that stable backports target: a kobject that device_initialize() never touched warns and its saturated refcount keeps the object allocated for good. Rejecting before the allocation needs no cleanup on any tree. Reproduced with an emulated RMI4 device driven over /dev/uhid, and again over dummy_hcd plus raw-gadget, on v6.12.69 booted slub_debug=3DFZPU and on v6.12.105 built with CONFIG_KASAN=3Dy. After this change the same device gets rmi4_physical rmi4-03: F40: interrupt count changed between PDT scans (pos 1 + 6 > 1) rmi4_physical rmi4-03: Function creation failed with code -22. and a device that answers both scans consistently still probes normally. Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI= 4 devices") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Assisted-by: GLM:glm-5.3 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> --- Changes in v4: - No code change: adds the Assisted-by tags required by Documentation/process/coding-assistants.rst. Changes in v3: - Validate before rmi_alloc_function() instead of freeing after it; no disposal is needed on any tree this way. See the cover letter. Changes in v2: - Dispose of the rejected function with kfree() instead of put_device(). See the cover letter. drivers/input/rmi4/rmi_driver.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_drive= r.c index 5d49a9021c7d..f66be55677a9 100644 --- a/drivers/input/rmi4/rmi_driver.c +++ b/drivers/input/rmi4/rmi_driver.c @@ -885,6 +885,25 @@ static int rmi_create_function(struct rmi_device *rmi_= dev, rmi_dbg(RMI_DEBUG_CORE, dev, "Initializing F%02X.\n", pdt->function_number); =20 + /* + * irq_mask[] was sized from the interrupt count collected by the + * earlier rmi_count_irqs() scan of the PDT, and irq[] holds + * RMI_FN_MAX_IRQS entries. Nothing guarantees that this scan sees + * the same table -- the PDT is read back from the device every + * time -- so a device that grows its interrupt counts between the + * two scans would push the set_bit() calls below past the end of + * the flexible array. Refuse the function instead, before anything + * is allocated for it. + */ + if (pdt->interrupt_source_count > RMI_FN_MAX_IRQS || + *current_irq_count + pdt->interrupt_source_count > data->irq_count) { + dev_err(dev, + "F%02X: interrupt count changed between PDT scans (pos %u + %u > %d)\n", + pdt->function_number, *current_irq_count, + pdt->interrupt_source_count, data->irq_count); + return -EINVAL; + } + fn =3D rmi_alloc_function(rmi_dev, pdt->function_number); if (!fn) { dev_err(dev, "Failed to allocate memory for F%02X\n", --=20 2.43.0