GHSA-MWJ6-9JPH-6QP6
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-64273"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:07Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: iforce - bound the device-reported force-feedback effect index\n\niforce_process_packet() handles a status report (packet id 0x02) by\ntaking a force-feedback effect index straight from the device wire and\nusing it to address the per-effect state array:\n\n\ti = data[1] \u0026 0x7f;\n\tif (data[1] \u0026 0x80) {\n\t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED,\n\t\t\t\t iforce-\u003ecore_effects[i].flags))\n\t\t\t...\n\t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED,\n\t\t\t\t iforce-\u003ecore_effects[i].flags)) {\n\t\t...\n\t}\n\nThe index is masked only with 0x7f, so it ranges 0..127, but\ncore_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index\nof 32..127 the test_and_set_bit()/test_and_clear_bit() is an\nout-of-bounds single-bit read-modify-write past the array. core_effects[]\nis the second-to-last member of struct iforce, so the write lands in the\ntrailing members and beyond the embedding kzalloc()\u0027d iforce_serio /\niforce_usb object.\n\ndata[1] is unvalidated device payload on both transports (the USB\ninterrupt endpoint and serio), and the status path is not gated on force\nfeedback being present, so a malicious or counterfeit device can set or\nclear a bit at an attacker-chosen offset past the object.\n\nReject an out-of-range index instead of indexing with it. Bound against\nthe array dimension IFORCE_EFFECTS_MAX rather than dev-\u003eff-\u003emax_effects so\nthe check guarantees memory safety regardless of how many effects the\ndevice registered. A legitimate \"effect started/stopped\" status always\ncarries an index below IFORCE_EFFECTS_MAX, so well-formed devices are\nunaffected; the neighbouring mark_core_as_ready() loop is already bounded\nand is left untouched.",
"id": "GHSA-mwj6-9jph-6qp6",
"modified": "2026-07-25T12:31:28Z",
"published": "2026-07-25T12:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64273"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e9943d2e4c63496b6ca84bc66fd3c71d40558e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c0f2901c9d325d4a0574c4237fd507810d225ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70019779325f2bb5f5a4098e91e79c655f50fcef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a40250f97c312e000e3616c9074022311a0efbc3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1b79e89bc33e4c682d3df7ae2aadc62b5a0c310"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c21295616a8a52b9a5f18cd4ca8c73030eda3d4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d10b0507fa0f5b46764b178e3271f9012f2df677"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5fa31f0550b55d80045669ae9080dd5b88abffa"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.