In the Linux kernel, the following vulnerability has been resolved:
Input: iforce - bound the device-reported force-feedback effect index
iforceprocesspacket() 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 coreeffects[] holds only IFORCEEFFECTSMAX (32) entries. For an index of 32..127 the testandsetbit()/testandclearbit() is an out-of-bounds single-bit read-modify-write past the array. coreeffects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforceserio / iforceusb 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 IFORCEEFFECTSMAX rather than dev->ff->maxeffects 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 IFORCEEFFECTSMAX, so well-formed devices are unaffected; the neighbouring markcoreasready() loop is already bounded and is left untouched.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64273.json"
}