Re: [PATCH 0/2] (no cover subject)

[Dmitry Torokhov]

On Sun, Jun 14, 2026 at 12:36:10AM -0500, Bryam Vargas via B4 Relay wrote:
> From be2c4843f6145374f28edd25cef43c9373542874 Mon Sep 17 00:00:00 2001
> Message-ID: <cover.1781415009.git.hexlabsecurity@xxxxxxxxx>
> From: Bryam Vargas <hexlabsecurity@xxxxxxxxx>
> Date: Sun, 14 Jun 2026 00:30:09 -0500
> Subject: [PATCH 0/2] Input: synaptics-rmi4 - fix out-of-bounds keymap access on large GPIO counts
> 
> The RMI4 F3A and F30 function handlers size their GPIO/LED key map to
> min(device_gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
> then consume that map with the full, unclamped device-reported count in
> two places: the attention-interrupt report loop, and input->keycodemax
> (while input->keycode points at the small allocation).
> 
> A device that reports a GPIO/LED count greater than 6 therefore yields a
> key map of at most 12 bytes that is indexed up to count-1:
> 
>   - rmi_f3a_attention() / rmi_f30_attention() read gpio[led]_key_map[i]
>     out of bounds on every attention interrupt (device-triggered), and
> 
>   - the input core's default keymap ioctls bound the index only against
>     keycodemax, so EVIOCGKEYCODE reads adjacent slab memory back to user
>     space and EVIOCSKEYCODE writes a caller-controlled u16 past the
>     allocation -- a controlled out-of-bounds heap write reachable by any
>     process that can open the evdev node.
> 
> Both handlers have the same shape; F3A was copied from F30. Patch 1 fixes
> F3A, patch 2 fixes F30. The one-line fix in each sizes the key map to the
> full device count; the mapping loop is unchanged (it still populates only
> the first min(count, 6) entries, the rest stay KEY_RESERVED and are
> skipped on report), and keycodemax now matches the allocation, closing
> the interrupt and both ioctl paths.
> 
> Reproduced with KASAN on a faithful in-kernel model of each handler
> (kmalloc-16 bucket, 12-byte request, reported count = 127):
> 
>   # without the patch -- attention read path
>   BUG: KASAN: slab-out-of-bounds in rmi_f3a_attention
>   Read of size 2 ... 0 bytes to the right of allocated 12-byte region
>     ... cache kmalloc-16
> 
>   # without the patch -- EVIOCSKEYCODE write path
>   BUG: KASAN: slab-out-of-bounds ...
>   Write of size 2 ... 0 bytes to the right of allocated 12-byte region
> 
>   # with the patch (key map sized to the full count): clean
>   # benign device (reported count <= 6): clean
> 
> The full read and write splats and a 32/64-bit ASan model of the same
> geometry are available on request.

Applied the lot, thank you.

-- 
Dmitry