From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 C706134404E for ; Mon, 24 Aug 2026 05:50:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550621; cv=none; b=CFbNPjSc/JHG0EIKlYAMkSL1BcZIhMmuFUoMQyapdOp13HHF09RWa7N1E7VvJIBtP+neFCkpWXb1lcr6RtU50A0+oXRWlOOXLHwaHwqc6j5zSZJpEee8LZ3oNd1b0rlaAF2R2A2PR7iIvVR9xz0cPtwbHiAH+Q9mmH2kvkYcFwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787550621; c=relaxed/simple; bh=LKqlCrOkqJ+yHwu2xim2fGa59Ex5ZiUy4lgPkuA0YTo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=BKzQgeqSbEfGC6lMCvKWMdj0DO1+oJmd7Ho3Z4XzALGU1dO/DdeCtCPOl8MoD6yZVj6apaKdzvB51dYWBKeUpPQIxkkOS6Odupps0/VRRhMFW8n8J0RK9GUR6xcWR2mSqTW0MR20fKyHGc1coIkOtjRc7qhrOl9o5AnFRUE8PAY= 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=B67zjBf9; arc=none smtp.client-ip=209.85.214.173 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="B67zjBf9" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2d049069377so25494235ad.0 for ; Sun, 23 Aug 2026 22:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787550619; x=1788155419; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=yVJTYkkQH5gOYluDI9SFf2oC6ea5cSp1/xayNBayQbA=; b=B67zjBf9VJl3XAm8DN9pCoYI14czMxp5k2G+0lTHP5gx95MFSXjP9HlelXpiGolJn+ eVeL0MV1s5uGNuIVrU5RrlJelx1sBawTZouAxb5YYsdF5YXQ+d3F21+mbwu0d03njO+J JkSZ4FYL7THUUYdD9BWOMDvUuFnTIKM7Dd55++nUI391sQE4ibWFQTNnHTnvX65wTCBO JM9jxEG8kGPK95Q2SyHmrClcPDE1LePg5zptmNPvY6nly7J2exSuuhqIJ+xfOYGtjLgU EiXaUIIaK1X8QKamqzq+Xo0iWZk1t9PPOe6NACNie0xjYA4CRs8TNmEdtP/1tIv/Z36+ V+LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787550619; x=1788155419; h=content-transfer-encoding:mime-version: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=yVJTYkkQH5gOYluDI9SFf2oC6ea5cSp1/xayNBayQbA=; b=CGw0ScEN2hqdHckZmqZ7J5vUy8B0muocv4WiyT6wazFyJsCsem8CqyU5ChfdwZMQp7 Digqxih3P9lczIc7MC98LOYrvcLV8HYdzbAgv1473+0OipXajdftEAlof8Nvv+caUbQf kEhXgBsXoR0LspAyFKKdb/4jMKUNSukdC0tT6KHsJx0V5UrXgoSYap4OswIhHSG+ksOL h2uUsAIPVZd1wGgUS6yzzF3thbUtaY1QeyFvLDysGKK6ear2CLNft36LCNuejo5RGyLP oPzqdgAHFQqlrl7YVXcfsbaIu+VP4vftdsP8BEv85CBtzI5tGnuvot8Z5aWio4I28Zg8 wlHg== X-Forwarded-Encrypted: i=1; AHgh+Ro0ePPrpI8qJSa+mh5T9aGrVi3iyyPF8th778QPYyExFcApOW1x3qm5XWh3Qyn0LiySwk5duTTLq+47tD4=@vger.kernel.org X-Gm-Message-State: AFuF++lGgkO6bnt1lvwUXdF6QPFdWubNBzlP+4HWAuKRTcNqQ5+NSdRX D3cRcow/QLUcrH74aXHbgfnlO+u3bMzsQnyw7i7lAaCBCB1NRps35xk4 X-Gm-Gg: AR+sD11G0pnN8skCcSQ9OjJWfMR5bsxjMWhZMbJTdytvH/K4TfVFGwz85nyTiI078n2 pbOVvOzzPZLenUVrC+TuXcICuvDi6wBe6yd/KTVT6NZtAja2IDKJmNWyx0IstHbCFDp5TrJ3cY9 oXXu3/gsXzekUuqVdQcvhEFd7DgpvCks34sSBS/T1tyTlftl/0VlzMKjp2UDLTX3KPkbqpaQISn rwu70RnAWlIZhu3Qz/R+q2nH0AiNBBsnAfe2AIPVACW2FvzI+LOa/PIQJTNFk8zMbUJaJAZcpRD Jn5uMEutAwgbRU/WYNHmbKGOer9wdqUmnfaxi9PxfhdO2jSzLLokmdPg5SPlmElNXk5E+9EOWl/ 4OiM8rlcyU8zQPJbUILITfPudQksSc5FMofcw/mkdOw3xaXBPgyYx+hSP+HBEhAOd7cq+l8BFws SSRbMJsnAG1KnZrEr9lJUZgvGjTdjW1QgSeE3iOM10pZoMmrXv08Jep5dcTCbq5qafzhiP/Bpzr lJMciXuSDRJB3YS7ZLF72HGQ6y1tCJDZKeoNtQ7LpeBkGeiUMsX888zQD8ue+gFE4FwtYp8EXf6 K9ku15PAOx7q+aSmBO8RoxHfXLRrEkh2unw= X-Received: by 2002:a17:902:d544:b0:2d3:a6db:299 with SMTP id d9443c01a7336-2d64adec78fmr462478795ad.6.1787550619067; Sun, 23 Aug 2026 22:50:19 -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.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Aug 2026 22:50:18 -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 0/2] Input: synaptics-rmi4 - fix two device-controlled out-of-bounds writes Date: Mon, 24 Aug 2026 13:50:10 +0800 Message-ID: X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Dmitry, While putting together a reproducer for an out-of-bounds bug in hid-rmi (v2 posted separately, [1]) I found two further memory-safety problems in the shared RMI4 core. Both are driven entirely by data the *device* supplies -- its Page Description Table -- so they are reachable from a malicious USB HID device with no code running on the victim, and equally from I2C and SMBus RMI4 devices. Neither depends on the hid-rmi bug; they are in drivers/input/rmi4/ and need fixing separately. Both are present in mainline and in every stable tree I looked at. 1/2 is an off-by-one: RMI_PDT_INT_SOURCE_COUNT_MASK is 0x07, so interrupt_source_count can be 7, but struct rmi_function declares int irq[RMI_FN_MAX_IRQS] with RMI_FN_MAX_IRQS == 6 and two loops walk it up to fn->num_of_irqs. irq[6] is the storage of the next member, unsigned int irq_pos, so the function's position in the interrupt bitmap is silently replaced with a Linux virq number. UBSAN flags all five stores plus the read on the unregister path. 2/2 is a time-of-check/time-of-use across two reads of the device: the PDT is scanned three times and re-read from the device every time, irq_mask[] is sized by the counting scan and filled by the creating scan, and nothing verifies the two agree. KASAN catches the resulting set_bit() walking off the end of the flexible array at the tail of every struct rmi_function. How this was verified --------------------- Linux v6.12.69 (CONFIG_UBSAN_BOUNDS=y, booted slub_debug=FZPU) and v6.12.105 (CONFIG_KASAN=y + CONFIG_KASAN_INLINE=y, CONFIG_UBSAN_BOUNDS=y, booted kasan_multi_shot -- generic KASAN otherwise reports only the first error per boot), x86_64. An emulated Synaptics RMI4 device publishes a Page Description Table crafted for each case. Two independent reproducers, giving identical results: - a /dev/uhid program -- no hardware, fully deterministic, and the easy one to run; - the same device over dummy_hcd + raw-gadget with Facedancer, so the reports really traverse usbcore -> usbhid -> hid-rmi. Each bug was exercised on its own cold boot, because heap state left by a previous run changes what the out-of-bounds read returns and UBSAN reports each call site only once per boot. With both patches applied 1/2 produces no UBSAN reports and the same device -- F01 declaring the full 7 interrupt sources -- probes normally, and 2/2 fails the probe cleanly instead of corrupting the heap. I am happy to post the reproducers, or to send them privately if you would rather they did not go to a public list. [1] https://patchwork.kernel.org/project/linux-input/patch/00a489f38b240624dcb5a4bae36a53fcba9cfb47.1787549195.git.98lawweijie@gmail.com/ Wei Jie Law (2): Input: synaptics-rmi4 - fix irq[] overrun with 7 interrupt sources Input: synaptics-rmi4 - reject a PDT that grows between scans drivers/input/rmi4/rmi_bus.h | 9 ++++++--- drivers/input/rmi4/rmi_driver.c | 18 ++++++++++++++++++ 2 files changed, 24 insertions(+), 3 deletions(-) -- 2.43.0