All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: hexlabsecurity@proton.me
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Guenter Roeck <linux@roeck-us.net>,
	Benjamin Tissoires <bentiss@kernel.org>
Subject: Re: [PATCH] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
Date: Thu, 25 Jun 2026 22:19:32 -0700	[thread overview]
Message-ID: <aj4LoEHHCMqUnyy2@google.com> (raw)
In-Reply-To: <20260613-b4-disp-6721686c-v1-1-4d5bb84ee520@proton.me>

Hi Bryam,

On Sat, Jun 13, 2026 at 11:01:16PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
> 
> rmi_f54_work() reads a diagnostics report from the device into
> f54->report_data, sizing the transfer with rmi_f54_get_report_size():
> 
> 	report_size = rmi_f54_get_report_size(f54);
> 	...
> 	for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
> 		int size = min(F54_REPORT_DATA_SIZE, report_size - i);
> 		...
> 		rmi_read_block(.., f54->report_data + i, size);
> 	}
> 
> report_data is allocated once at probe from F54's own electrode counts
> (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))),
> but rmi_f54_get_report_size() computes the size from
> drv_data->num_*_electrodes when those are set, i.e. from the F55
> function's electrode counts. Both counts come straight from device
> queries (F54 and F55 each report up to 255 electrodes) and nothing
> constrains the F55 counts to the F54 ones.
> 
> A malicious or malfunctioning RMI4 device that reports larger F55
> electrode counts than its F54 counts makes report_size exceed the
> allocation, so the read loop writes past report_data (and the V4L2
> dequeue memcpy() then reads past it). On conforming hardware the F55
> configured electrodes are a subset of the F54 physical electrodes, so
> report_size never exceeds the buffer and well-behaved devices are
> unaffected.
> 
> Record the allocation size and reject a report that does not fit,
> mirroring the existing zero-size check.
> 
> Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>

Thanks for the patch. It makes sense, but there are more changes needed
in F54. I incorporated it in the series I just posted, would appreviate
if you could review it.

Thanks.

-- 
Dmitry

      parent reply	other threads:[~2026-06-26  5:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14  4:01 [PATCH] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer Bryam Vargas
2026-06-14  4:01 ` Bryam Vargas via B4 Relay
2026-06-14  4:14 ` sashiko-bot
2026-06-26  5:19 ` Dmitry Torokhov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aj4LoEHHCMqUnyy2@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=bentiss@kernel.org \
    --cc=hexlabsecurity@proton.me \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.