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