CVE-2026-64277

In the Linux kernel, the following vulnerability has been resolved:

Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count

rmi_f3a_initialize() takes the GPIO count from the device query register

(f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127).

rmi_f3a_map_gpios() then allocates gpio_key_map with

min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but

rmi_f3a_attention() iterates the full gpio_count and dereferences

gpio_key_map[i], and input->keycodemax is set to the full gpio_count

while input->keycode points at the 6-entry allocation.

A device that reports gpio_count > 6 therefore causes an out-of-bounds

read of gpio_key_map[] on every attention interrupt, and out-of-bounds

accesses through the input core's default keymap ioctls: EVIOCGKEYCODE

reads past the buffer (leaking adjacent slab memory to user space) and

EVIOCSKEYCODE writes a caller-controlled value past it, for any process

able to open the evdev node, since input_default_getkeycode() and

input_default_setkeycode() only bound the index against keycodemax.

Size the keymap for the full gpio_count. The mapping loop is unchanged:

it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)

entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)

and are skipped when reporting.