CVE-2026-64273

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

Input: iforce - bound the device-reported force-feedback effect index

iforce_process_packet() handles a status report (packet id 0x02) by

taking a force-feedback effect index straight from the device wire and

using it to address the per-effect state array:

i = data[1] & 0x7f;

if (data[1] & 0x80) {

if (!test_and_set_bit(FF_CORE_IS_PLAYED,

iforce->core_effects[i].flags))

...

} else if (test_and_clear_bit(FF_CORE_IS_PLAYED,

iforce->core_effects[i].flags)) {

...

}

The index is masked only with 0x7f, so it ranges 0..127, but

core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index

of 32..127 the test_and_set_bit()/test_and_clear_bit() is an

out-of-bounds single-bit read-modify-write past the array. core_effects[]

is the second-to-last member of struct iforce, so the write lands in the

trailing members and beyond the embedding kzalloc()'d iforce_serio /

iforce_usb object.

data[1] is unvalidated device payload on both transports (the USB

interrupt endpoint and serio), and the status path is not gated on force

feedback being present, so a malicious or counterfeit device can set or

clear a bit at an attacker-chosen offset past the object.

Reject an out-of-range index instead of indexing with it. Bound against

the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so

the check guarantees memory safety regardless of how many effects the

device registered. A legitimate "effect started/stopped" status always

carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are

unaffected; the neighbouring mark_core_as_ready() loop is already bounded

and is left untouched.