CVE-2026-64273: Input: iforce - bound the device-reported force-feedback effect index
Greg Kroah-Hartman <[email protected]> Sat, 25 Jul 2026 10:48:10 +0200
| Newsgroups | org.kernel.vger.linux-cve-announce |
|---|---|
| Message-ID | <2026072500-CVE-2026-64273-0188@gregkh> |
From: Greg Kroah-Hartman <[email protected]> Description =========== 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. The Linux kernel CVE team has assigned CVE-2026-64273 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.10.261 with commit b1b79e89bc33e4c682d3df7ae2aadc62b5a0c310 Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 5.15.212 with commit d10b0507fa0f5b46764b178e3271f9012f2df677 Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.1.178 with commit 6c0f2901c9d325d4a0574c4237fd507810d225ff Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.6.145 with commit c21295616a8a52b9a5f18cd4ca8c73030eda3d4f Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.12.96 with commit e5fa31f0550b55d80045669ae9080dd5b88abffa Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.18.39 with commit 70019779325f2bb5f5a4098e91e79c655f50fcef Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 7.1.4 with commit a40250f97c312e000e3616c9074022311a0efbc3 Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 7.2-rc1 with commit 0e9943d2e4c63496b6ca84bc66fd3c71d40558e2 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-64273 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/input/joystick/iforce/iforce-packets.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/b1b79e89bc33e4c682d3df7ae2aadc62b5a0c310 https://git.kernel.org/stable/c/d10b0507fa0f5b46764b178e3271f9012f2df677 https://git.kernel.org/stable/c/6c0f2901c9d325d4a0574c4237fd507810d225ff https://git.kernel.org/stable/c/c21295616a8a52b9a5f18cd4ca8c73030eda3d4f https://git.kernel.org/stable/c/e5fa31f0550b55d80045669ae9080dd5b88abffa https://git.kernel.org/stable/c/70019779325f2bb5f5a4098e91e79c655f50fcef https://git.kernel.org/stable/c/a40250f97c312e000e3616c9074022311a0efbc3 https://git.kernel.org/stable/c/0e9943d2e4c63496b6ca84bc66fd3c71d40558e2