From nobody Mon Sep 28 09:57:57 2026 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 0540834404E for ; Mon, 24 Aug 2026 05:50:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550629; cv=none; b=o/DlG/NO220eq6sySj/aaE2dKP7TyKYknDoD8IaCijuu4BtEwZyD+/KWmQOaj/N/6FdhtkTL6y2hurYyVo8/vuz2ct3GhiMd7KTv4dTNsDjXzTbzEJUYQWXQUvFhBGasvVVh05ZD2QIb2cm1M8OLUFV0IESDfGsQKBG9GlolMyg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550629; c=relaxed/simple; bh=WZE0UAjryG3LKGmJlWlrF4NVV/WeS+t9+KyPhRYEdqo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dIVLVBzNT6AiVaS+ZaeNLOhwh8D4KDKFECWoDAnnfrTfbRriztuWWwu8d7QhaDplLcUYxVm5o91maFnN6OVPKEwF77TZC5MYoQg4n4kq7A24m30yZUJNi4IWDQu9xVG0dSFpS4zCu4wBPMA+9aORPEyc5Yshvl8GAukxqJJbWFw= 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=b3Yq0NfM; arc=none smtp.client-ip=209.85.214.169 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="b3Yq0NfM" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2d049069377so25494775ad.0 for ; Sun, 23 Aug 2026 22:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787550627; x=1788155427; 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=EB3wFOXHlXyIKQOwKFQXlogVT9fQ7bqKTlFugd3hmJ4=; b=b3Yq0NfM2W2WY7nw9PUixGDdTxFA0LFPnu80kJG80gTDj/3QER/9SFE4pmwbyr+xow pKgoYMwOw4AcbIlVCsyhVja9KyUTKH68ZG+jreIKFpv5abtQ+b27BNy8IJnrRT/vkk50 EYx1ePF054OKarryHm5qsxneeCWjYe2vigG0PObtBlGzZezGMztYRx6HzDaSeWvZAHYK /dBIv1UK9xwCkc3mPef2BNlEcmv84mO3FKkV8AkHu/8Iom/+oVLnkWuPRps1qDInLH0M dIOFICiRiFRp/oCUj1p2PIA9NAiLiGZdR5FcmDqrDm27k1HaQfjR2bY+p2xe+UFQJ0G4 rFog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787550627; x=1788155427; 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=EB3wFOXHlXyIKQOwKFQXlogVT9fQ7bqKTlFugd3hmJ4=; b=YSQYUNDp5NfN3hURRu5+OSUrKlWFhB8ay+P0RFAvRWx4njCB/GD28QDtEUTuR8CbcY WqsLz9Ai0NfpCic70+BAON1nEQvsPaEWMnYBLuSHxfYdQ+xLMg3iMi6/3QplTYxM7GgT MwHZ3Q9cR/kV6NFqQHmZuIqg1zw3Mlj6mVv4Q7RuhXVarNhOsWlOXsdHwcwPJh2myxpQ w6FJd5YvJ0Ya0cI7aU0Hl6EQQ8ayTvoJH0/TFXK98jCfrB4dX1eHcDIHP5Mg7Y//AtR3 GLJqAjZY7rmU0edQNNqXmz6a8btX7L4DZgrEwAXbLtUBQYL8FRyEkXdpE4bcY3EeuHuM kGTA== X-Forwarded-Encrypted: i=1; AHgh+RqJt3ijBQujXPtEylPVx5iW6iIvpmnhuTjctEsRuUk7clT2Ad55yoW7NXzykijGNeWkXbjz3+7uLfOCn68=@vger.kernel.org X-Gm-Message-State: AFuF++n2CSS6jwlzzyCs3qH3GOh8G3w6yPmjnYZl5/olUEbNzw9hJdMw cxvFN8evLJONWfJUxIl36AaHEAqddLfXZutWX/9Bq++ic9aqwGAB7fzA X-Gm-Gg: AR+sD10N/rPsMF7xX71R96P6zewNVvqFG9Lf4L4toEwgo7T7Xe2OC6jLvTamdurabrc RWRoW2PGcQHCjMzFPekupAxGkgonaGH6tXsfTnnHM2MR/NCGLF1ktKy1z+YihjMkLZfzEmTBsi4 b9Es2Gnri0x9uaj0YeWyLAEmc+QZdsG22Dmxy7O1WPqP09Vd7G869uNAu0KRqjwwYy/ytZkFx34 UCJuR8WRV2Fae0xuNpYDY0taYruUaoDNvFszSUyzvCZZNyrN58eth9s5YcyuxchYy4053QzsmqK dGl+WlSDctmrvvx16gjGis8h1APZnZfVzjGkljOdQayGs0mHgUBqCSEuBjKxHXy1QBr+Oh+te6l Gj/cgxsakrO/QlBrxxmBx/GuKinPHmhuEiudnh4d+PO+6LgmWHNFKDQUG6/5n+SMgGEvh44rzrF mIXQbmSVp2yle3QqN102xolKuZUSqOJD2/LXcOj4vr6LbZcLmPczCgXicrlhr/dRSz0xtuPWduS K7D9r6xo6bEYJgGj1rNXsYxVyYndCgfFZ3sz6IWWFyXyyInYIm1cA+z+b4sjGXYz0UmSz5SYCpj jm6mcSORH9J8ICJlyYkblP+w X-Received: by 2002:a17:903:354b:b0:2ca:f21a:a6c5 with SMTP id d9443c01a7336-2d64ada70cemr430814115ad.1.1787550627273; Sun, 23 Aug 2026 22:50:27 -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 d9443c01a7336-2d6768c9876sm13955655ad.68.2026.08.23.22.50.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 22:50:26 -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 1/2] Input: synaptics-rmi4 - fix irq[] overrun with 7 interrupt sources Date: Mon, 24 Aug 2026 13:50:11 +0800 Message-ID: <4a48122167e32a6755d9ee7033f29bf7c78be796.1787549234.git.98lawweijie@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> --- 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 09:57:57 2026 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 E9B043DDDDD for ; Mon, 24 Aug 2026 05:50:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550632; cv=none; b=h6SW5mgeY5acJ55A/bBLIgPHM+aY3r0ueqzRB0raa2ZJsr0xZF0GiWVTjQDURbMCNnMnVYKzwWQQzGGWMsDvZGpAbZasSKzJbSMcF8dzE3r7heIYwGakWSf59Ui6hnw9jpSjzH1x/5j1J7floZijTd0/GdaIRKlaPP7k2A/m9VE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550632; c=relaxed/simple; bh=ILGgGBJIjFFiPwTQaTOvL/nQywIa0UNzzJZhVum0lV8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tTwUXHERxoT7bkpusO1VY/XRPJMSBV9POOwrQLWFfml1TAu/E8zNZLqYA9wGw5s9RN9UGjgTO1otRHmK7L73wRbS9nydF7ethD2vQCtacCRRq5T/EVp/QcW4fYmuBtcH0oDF4hWgsYGhk18MpTkgN/PxMFU3ZfUu2yx4/R+yOgk= 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=XTq0NYKY; arc=none smtp.client-ip=209.85.214.172 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="XTq0NYKY" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2d6af66ca14so5328175ad.1 for ; Sun, 23 Aug 2026 22:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787550630; x=1788155430; 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=4eujiq6V03TrGWMcsHjzyrL4w51Ezbmmle/EXKToc6k=; b=XTq0NYKY+cVGL+TLnihE+3Wgqf/0DrID52UVCjcKGSZKotDyE4CdPIWgUyYpU4TFLz Z42HRTTq6rzg695RC0yM6IlbS579zyeg3KISxdeHHxLe6BQ888WpSo9FAJ4k/crSIKUp VpCS484WFEBP4r80vGRVzrqj2x9FnUc6BylT9AuNjKq3iqJWj8GUZUMQogPAXJ4XwEfS 0v2D2piz2YudAy1Vf0UDp6VafWPdnoLTIaKemGF+FxSZbycxFnBNZFOHw4DB4b3DLLsR +tLNC2DcAOTQe4n9WWIBU+NoehX+4PIg1ceJl2EKRyJCXMdcyldNUIiDGXyUASQtK5ZB I/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787550630; x=1788155430; 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=4eujiq6V03TrGWMcsHjzyrL4w51Ezbmmle/EXKToc6k=; b=mSAYlcAstO9u9bvnZUEW5ArAlAtpV4ysdNHxXMCN9eAv1WcwGmGdepPMXOtRxYsa1Q 56xW2uDy2NT7+SoML70QO/8d/+BFSu9ZcCieUbTIO9NSPS9w2tH7pE5Pbd0JFyTxx03M iIFdr+bPJx5EgllzMrkPSYI3bTrEQZOxQ2ZN1TMAJfa425yAcSwsPWFbzYTvKpw1sZcQ rbNShTh5pHvN64+kZdTS4ZBKf87UFFyIJ9RCSF0Fhb7VLiYqN1qXjQq+RXffHoAUSiiR O26FuQsx+DNh/W6L2whz6KjIRlENWjL42yFZG58rWnW/jAU/3htlBISjuJJiyx+ghcYb r9/A== X-Forwarded-Encrypted: i=1; AHgh+RoUB+emgKMVPunKKXkTfpiWeJGj8XnyQgMliHxuZ22UI+KBoPZ7AkNEoRijjfNzf7MTJg6iByODtXg9Pjk=@vger.kernel.org X-Gm-Message-State: AFuF++k5tXwmO5H2dgCZW46Pu13EjHESjwhDGo3CKsiSGQs4ehao4Nmr qKLf9v8JHgGsEG/x5J6nGKbdWKdD3JLtyjYOYmQ1MKjOSbY8bSK4rhaU X-Gm-Gg: AR+sD10RQBpDamvi6ZpDwcwj0JvlihfMGD4DG2K6ra3xlvw0l89kqSlRRiMCo0Rvm7R bq5JXjJYsFQdcljhVoqnKofUMFiN0d9TUkVIEBd1LZ8yT2Rj38blnhzz4fg0QimZ3De/WViBK7d h5sYC/URmr1Wuhv5mSdFVb1vWRGSJD8kFetrolaCcuoNSMS91OyqSNTSJn+b/xOSe4Qg/aCC7L4 bvQ+U9WHSio3jEAtLtRQQQL6zTsoHD1r5U6I4QKGHCoSEUZAj2/fai49ifxMLaKM1r+aKL3eedT B0K43nZLYX9fQR06xE6pnfGA2mDkvJ2E30JihHEQhIOlb+0xNNKPnFF6W3EtJzf5QneZQMh0jEe hJV6vI1msECEI0KB00VR5uk2wgi8oa5qX1U6CO7jF71/Tfr5AXM7UqvUh1t2H+pbV5WWvYEXLja +5d3yTwHOnUKS0NASUpWRhz1w18hg1MyXTPaTRAmv9FBNXJn07GqG/z5Zhdd2S1RJsacqvNFO9r jO8tv71tuneY3zIU6y6JbKl19TBIdbYyutvUC9QHp+KkhvqAO/Vczj4FOL54Y9T5Ysk1U7t4TMu wKvM3N9INdEnWRijc+kgCSD9KCzLOQ== X-Received: by 2002:a17:902:e804:b0:2c6:90ec:f601 with SMTP id d9443c01a7336-2d670bee7a0mr271595585ad.8.1787550630113; Sun, 23 Aug 2026 22:50:30 -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 d9443c01a7336-2d6768c9876sm13955655ad.68.2026.08.23.22.50.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 22:50:29 -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 2/2] Input: synaptics-rmi4 - reject a PDT that grows between scans Date: Mon, 24 Aug 2026 13:50:12 +0800 Message-ID: <2c26d7ce8c6b7371ab55607f53443961220e4b24.1787549234.git.98lawweijie@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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 position before using it and fail the probe instead. The check is exact, not conservative: when both scans see the same table, fn->irq_pos + fn->num_of_irqs is the running total that produced data->irq_count, so it never fires for a device that behaves. 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 Signed-off-by: Wei Jie Law <98lawweijie@gmail.com> --- drivers/input/rmi4/rmi_driver.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_drive= r.c index 5d49a9021c7d..c0e91a372eff 100644 --- a/drivers/input/rmi4/rmi_driver.c +++ b/drivers/input/rmi4/rmi_driver.c @@ -899,6 +899,24 @@ static int rmi_create_function(struct rmi_device *rmi_= dev, fn->irq_pos =3D *current_irq_count; *current_irq_count +=3D fn->num_of_irqs; =20 + /* + * irq_mask[] was sized from the interrupt count collected by the + * earlier rmi_count_irqs() scan of the PDT. 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 these set_bit() calls past the end + * of the flexible array. Refuse the function instead. + */ + if (fn->num_of_irqs > RMI_FN_MAX_IRQS || + fn->irq_pos + fn->num_of_irqs > data->irq_count) { + dev_err(dev, + "F%02X: interrupt count changed between PDT scans (pos %u + %u > %d)\n", + pdt->function_number, fn->irq_pos, fn->num_of_irqs, + data->irq_count); + put_device(&fn->dev); + return -EINVAL; + } + for (i =3D 0; i < fn->num_of_irqs; i++) set_bit(fn->irq_pos + i, fn->irq_mask); =20 --=20 2.43.0