All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: hexlabsecurity@proton.me
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: iforce - bound the device-reported force-feedback effect index
Date: Mon, 22 Jun 2026 20:53:55 -0700	[thread overview]
Message-ID: <ajoDJ82Csta196ja@google.com> (raw)
In-Reply-To: <20260613-b4-disp-4828d263-v1-1-02320e1a89dd@proton.me>

On Sat, Jun 13, 2026 at 09:58:55PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
> 
> 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.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>

Thank you, applied (but I dropped the temporary 'flags').

-- 
Dmitry

      parent reply	other threads:[~2026-06-23  3:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14  2:58 [PATCH] Input: iforce - bound the device-reported force-feedback effect index Bryam Vargas
2026-06-14  2:58 ` Bryam Vargas via B4 Relay
2026-06-14  3:10 ` sashiko-bot
2026-06-23  3:53 ` Dmitry Torokhov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ajoDJ82Csta196ja@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=hexlabsecurity@proton.me \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.