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…
Does this matter?
High impact if exploited, but EPSS currently rates exploitation as unlikely (0.17%). Schedule it in the normal patch cycle and watch for a rise in EPSS or a public exploit.
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.
- CVSS 3.1
- 7.8 HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- EPSS
- 0.17% probability · 6th percentile
- CISA KEV
- Not listed
- Weakness
- CWE-129
- Affected
- linux/linux kernel
- Source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
References
- https://git.kernel.org/stable/c/0e9943d2e4c63496b6ca84bc66fd3c71d40558e2Patch
- https://git.kernel.org/stable/c/6c0f2901c9d325d4a0574c4237fd507810d225ffPatch
- https://git.kernel.org/stable/c/70019779325f2bb5f5a4098e91e79c655f50fcefPatch
- https://git.kernel.org/stable/c/a40250f97c312e000e3616c9074022311a0efbc3Patch
- https://git.kernel.org/stable/c/b1b79e89bc33e4c682d3df7ae2aadc62b5a0c310Patch
- https://git.kernel.org/stable/c/c21295616a8a52b9a5f18cd4ca8c73030eda3d4fPatch
- https://git.kernel.org/stable/c/d10b0507fa0f5b46764b178e3271f9012f2df677Patch
- https://git.kernel.org/stable/c/e5fa31f0550b55d80045669ae9080dd5b88abffaPatch
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.