CVE-2026-64277

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count<br /> <br /> rmi_f3a_initialize() takes the GPIO count from the device query register<br /> (f3a-&gt;gpio_count = buf &amp; RMI_F3A_GPIO_COUNT, range 0..127).<br /> rmi_f3a_map_gpios() then allocates gpio_key_map with<br /> min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but<br /> rmi_f3a_attention() iterates the full gpio_count and dereferences<br /> gpio_key_map[i], and input-&gt;keycodemax is set to the full gpio_count<br /> while input-&gt;keycode points at the 6-entry allocation.<br /> <br /> A device that reports gpio_count &gt; 6 therefore causes an out-of-bounds<br /> read of gpio_key_map[] on every attention interrupt, and out-of-bounds<br /> accesses through the input core&amp;#39;s default keymap ioctls: EVIOCGKEYCODE<br /> reads past the buffer (leaking adjacent slab memory to user space) and<br /> EVIOCSKEYCODE writes a caller-controlled value past it, for any process<br /> able to open the evdev node, since input_default_getkeycode() and<br /> input_default_setkeycode() only bound the index against keycodemax.<br /> <br /> Size the keymap for the full gpio_count. The mapping loop is unchanged:<br /> it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)<br /> entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)<br /> and are skipped when reporting.