PT-2026-64494 · Linux · Linux
CVE-2026-64273
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux