CVE-2026-64273

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - bound the device-reported force-feedback effect index<br /> <br /> iforce_process_packet() handles a status report (packet id 0x02) by<br /> taking a force-feedback effect index straight from the device wire and<br /> using it to address the per-effect state array:<br /> <br /> i = data[1] &amp; 0x7f;<br /> if (data[1] &amp; 0x80) {<br /> if (!test_and_set_bit(FF_CORE_IS_PLAYED,<br /> iforce-&gt;core_effects[i].flags))<br /> ...<br /> } else if (test_and_clear_bit(FF_CORE_IS_PLAYED,<br /> iforce-&gt;core_effects[i].flags)) {<br /> ...<br /> }<br /> <br /> The index is masked only with 0x7f, so it ranges 0..127, but<br /> core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index<br /> of 32..127 the test_and_set_bit()/test_and_clear_bit() is an<br /> out-of-bounds single-bit read-modify-write past the array. core_effects[]<br /> is the second-to-last member of struct iforce, so the write lands in the<br /> trailing members and beyond the embedding kzalloc()&amp;#39;d iforce_serio /<br /> iforce_usb object.<br /> <br /> data[1] is unvalidated device payload on both transports (the USB<br /> interrupt endpoint and serio), and the status path is not gated on force<br /> feedback being present, so a malicious or counterfeit device can set or<br /> clear a bit at an attacker-chosen offset past the object.<br /> <br /> Reject an out-of-range index instead of indexing with it. Bound against<br /> the array dimension IFORCE_EFFECTS_MAX rather than dev-&gt;ff-&gt;max_effects so<br /> the check guarantees memory safety regardless of how many effects the<br /> device registered. A legitimate "effect started/stopped" status always<br /> carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are<br /> unaffected; the neighbouring mark_core_as_ready() loop is already bounded<br /> and is left untouched.