PT-2026-64498 · Linux · Linux
CVE-2026-64277
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux