[PATCH] Input: raspberrypi-ts - reject out-of-range point counts and slot IDs

[PATCH] Input: raspberrypi-ts - reject out-of-range point counts and slot IDs

[Linkai Gong]

rpi_ts_poll() copies a firmware snapshot and walks regs.point[] using
num_points. The array has RPI_TS_MAX_SUPPORTED_POINTS entries, and the
GPU is documented to report 0-10 points (99 invalidates the copy).

A corrupted count would index past that snapshot. Slot IDs are a 4-bit
field (0-15) while only 10 MT slots are allocated. Drop the whole frame
instead of clamping, so a bad report cannot update a subset of contacts.

Fixes: 0b9f28fed3f7 ("Input: add official Raspberry Pi's touchscreen driver")
Cc: stable@vger.kernel.org
Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
---
 drivers/input/touchscreen/raspberrypi-ts.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c b/drivers/input/touchscreen/raspberrypi-ts.c
index 841d39a449b3..bd63d95c094b 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -78,6 +78,7 @@ static void rpi_ts_poll(struct input_dev *input)
 		 ts->fw_regs_va + offsetof(struct rpi_ts_regs, num_points));
 
 	if (regs.num_points == RPI_TS_NPOINTS_REG_INVALIDATE ||
+	    regs.num_points > RPI_TS_MAX_SUPPORTED_POINTS ||
 	    (regs.num_points == 0 && ts->known_ids == 0))
 		return;
 
@@ -87,6 +88,9 @@ static void rpi_ts_poll(struct input_dev *input)
 		touchid = (regs.point[i].yh >> 4) & 0xf;
 		event_type = (regs.point[i].xh >> 6) & 0x03;
 
+		if (touchid >= RPI_TS_MAX_SUPPORTED_POINTS)
+			return;
+
 		modified_ids |= BIT(touchid);
 
 		if (event_type == RPI_TS_FTS_TOUCH_DOWN ||
-- 
2.25.1

Re: [PATCH] Input: raspberrypi-ts - reject out-of-range point counts and slot IDs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Returning early inside the touch reporting loop when encountering an out-of-bounds `touchid` leaves the input core with a partially updated, unsynchronized event frame, causing permanent ghost touches.

Pre-existing issues:
- [Critical] The driver fails to instruct the GPU firmware to stop writing to the physical DMA buffer before freeing it, resulting in a DMA use-after-free.
--

--- Patch [1]: [PATCH] Input: raspberrypi-ts - reject out-of-range point counts and slot IDs ---
commit f72d20735f09ac5b0ab187efd0cc082fb9bc5bcf
Author: Linkai Gong <gonglinkai@kylinos.cn>

Input: raspberrypi-ts - reject out-of-range point counts and slot IDs

This commit drops out-of-bounds point counts and adds a bounds check to
drop frames containing invalid slot IDs. This prevents corrupted touch IDs
from causing out of bounds accesses.

Cc: stable@vger.kernel.org

> diff --git a/drivers/input/touchscreen/raspberrypi-ts.c b/drivers/input/touchscreen/raspberrypi-ts.c
> index 841d39a449b37..bd63d95c094b9 100644
> --- a/drivers/input/touchscreen/raspberrypi-ts.c
> +++ b/drivers/input/touchscreen/raspberrypi-ts.c
> @@ -78,6 +78,7 @@ static void rpi_ts_poll(struct input_dev *input)
>  		 ts->fw_regs_va + offsetof(struct rpi_ts_regs, num_points));
>  
>  	if (regs.num_points == RPI_TS_NPOINTS_REG_INVALIDATE ||
> +	    regs.num_points > RPI_TS_MAX_SUPPORTED_POINTS ||
>  	    (regs.num_points == 0 && ts->known_ids == 0))
>  		return;
>  
> @@ -87,6 +88,9 @@ static void rpi_ts_poll(struct input_dev *input)
>  		touchid = (regs.point[i].yh >> 4) & 0xf;
>  		event_type = (regs.point[i].xh >> 6) & 0x03;
>  
> +		if (touchid >= RPI_TS_MAX_SUPPORTED_POINTS)
> +			return;

[Severity: High]
Does returning early here leave the input core with a partially updated,
unsynchronized event frame?

If earlier iterations of this loop processed valid contacts, returning here
aborts the processing after partial state mutations have already occurred.
This skips the required input_sync() call at the end of rpi_ts_poll(),
which could leave the input core with unsynchronized event state and cause
permanent ghost touches or stuck slots.

> +
>  		modified_ids |= BIT(touchid);
>  
>  		if (event_type == RPI_TS_FTS_TOUCH_DOWN ||

[ ... ]

[Severity: Critical]
This isn't a bug introduced by this patch, but does the driver fail to
instruct the GPU firmware to stop writing to the physical DMA buffer before
freeing it?

In rpi_ts_probe(), the firmware is instructed to asynchronously write to
the touch buffer:

	error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
				      &touchbuf, sizeof(touchbuf));

During device removal or unbind, rpi_ts_dma_cleanup() frees this buffer:

	dma_free_coherent(dev, PAGE_SIZE, ts->fw_regs_va, ts->fw_regs_phys);

Without a corresponding action to tell the firmware to stop writing to this
address (such as sending a value of 0), the firmware might continue to write
touchscreen coordinates to freed memory, leading to a DMA use-after-free
and silent memory corruption.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260820065340.3765457-1-gonglinkai@kylinos.cn?part=1

Re: [PATCH] Input: raspberrypi-ts - reject out-of-range point counts and slot IDs

[Dave Stevenson]

Hi Linkai

On Thu, 20 Aug 2026 at 08:29, Linkai Gong <gonglinkai@kylinos.cn> wrote:
>
> rpi_ts_poll() copies a firmware snapshot and walks regs.point[] using
> num_points. The array has RPI_TS_MAX_SUPPORTED_POINTS entries, and the
> GPU is documented to report 0-10 points (99 invalidates the copy).
>
> A corrupted count would index past that snapshot. Slot IDs are a 4-bit
> field (0-15) while only 10 MT slots are allocated. Drop the whole frame
> instead of clamping, so a bad report cannot update a subset of contacts.

This touch driver is only used with the original Pi DSI display when
used with the legacy, firmware driven, display stack. Raspberry Pi
have considered that display stack deprecated for at least 4 years.
Our guidance is to use the edt-ft5x06 driver alongside the vc4 DRM driver.

TBH I'd support dropping this driver entirely. Will anyone object if I
send a patch to do that?

> Fixes: 0b9f28fed3f7 ("Input: add official Raspberry Pi's touchscreen driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Linkai Gong <gonglinkai@kylinos.cn>
> ---
>  drivers/input/touchscreen/raspberrypi-ts.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/input/touchscreen/raspberrypi-ts.c b/drivers/input/touchscreen/raspberrypi-ts.c
> index 841d39a449b3..bd63d95c094b 100644
> --- a/drivers/input/touchscreen/raspberrypi-ts.c
> +++ b/drivers/input/touchscreen/raspberrypi-ts.c
> @@ -78,6 +78,7 @@ static void rpi_ts_poll(struct input_dev *input)
>                  ts->fw_regs_va + offsetof(struct rpi_ts_regs, num_points));
>
>         if (regs.num_points == RPI_TS_NPOINTS_REG_INVALIDATE ||
> +           regs.num_points > RPI_TS_MAX_SUPPORTED_POINTS ||
>             (regs.num_points == 0 && ts->known_ids == 0))
>                 return;
>
> @@ -87,6 +88,9 @@ static void rpi_ts_poll(struct input_dev *input)
>                 touchid = (regs.point[i].yh >> 4) & 0xf;
>                 event_type = (regs.point[i].xh >> 6) & 0x03;
>
> +               if (touchid >= RPI_TS_MAX_SUPPORTED_POINTS)
> +                       return;
> +

Can you just abort here?
If this was with i > 0 then there has already been 1 or more
input_mt_slot(), input_mt_report_slot_state(), and
touchscreen_report_pos() calls which update the device state.
True input_mt_sync_frame() / input_sync() haven't been called to
report the event to userspace, but my gut feel is that the next poll
won't necessarily reset those events in the device state. I'm happy to
be corrected by someone who knows the input subsystem better.

  Dave

>                 modified_ids |= BIT(touchid);
>
>                 if (event_type == RPI_TS_FTS_TOUCH_DOWN ||
> --
> 2.25.1
>
>