Re: [PATCH] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer

[Bryam Vargas]

Hi Dmitry,

Thanks for picking this up and keeping the authorship on 03.

> there are more changes needed in F54. I incorporated it in the series I
> just posted, would appreviate if you could review it.

Went through all ten. It holds together. A few things worth flagging:

Backport ordering is the one to act on. 03 leans on 02's control flow: its
report_size > max_report_size guard lands in the worker tail that 02 folds
into the single out: write. And 03's Fixes: c762cc68b6a1 (Nov 2016) postdates
02's Fixes: 3a762dbd5347 (Jul 2016), so any stable tree old enough to want 03
still carries the abort:/error: form 02 reworks; cherry-picking 03 alone
conflicts on that hunk, and 06 touches the same tail. Keeping 02 -> 03 -> 06
together for stable (or a dependency note on 03) keeps AUTOSEL from taking 03
on its own.

01 is correct but instance-complete: a device honestly reporting a large F55
num_tx still oversizes report_size until 03 lands. Maybe a line in its commit
log pointing at 03.

One aside, not for this series: F54_FIFO_OFFSET is 16-bit but report_size
reaches 2 * 255 * 255 = 130050, so past 65535 the start offset wraps and the
device reads from the wrong place. It stays in bounds (report_data + i tracks
the same product), so it's correctness, not safety; maybe a later guard.

Otherwise it's straightforward. For the series:

Reviewed-by: Bryam Vargas <hexlabsecurity@xxxxxxxxx>

03 is the one I sent, so drop it there. On the memory-safety patches I ran an
in-kernel A/B under KASAN: the unpatched arm overruns the plane (07), delivers
the stale frame (06), or overruns report_data (03's class); the patched arm is
clean. So for 05, 06 and 07:

Tested-by: Bryam Vargas <hexlabsecurity@xxxxxxxxx>

Thanks,
Bryam