Re: [PATCH] Input: iforce - bound the device-reported force-feedback effect index

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] A zero-length USB packet causes an integer underflow when calculating the packet length, leading to massive out-of-bounds reads and a kernel panic.
--

commit 03557dab27a995017f2c109d738ebd32fc4d550b
Author: Bryam Vargas <hexlabsecurity@proton.me>

Input: iforce - bound the device-reported force-feedback effect index

This commit bounds the force-feedback effect index reported by the device
to prevent an out-of-bounds read-modify-write past the core_effects[] array.
It fixes a memory corruption vulnerability caused by an unvalidated payload.

> diff --git a/drivers/input/joystick/iforce/iforce-packets.c b/drivers/input/joystick/iforce/iforce-packets.c
> index fd1cd731d781a..ff266568d586c 100644
> --- a/drivers/input/joystick/iforce/iforce-packets.c
> +++ b/drivers/input/joystick/iforce/iforce-packets.c
> @@ -186,14 +186,18 @@ void iforce_process_packet(struct iforce *iforce,
>  
>  		/* Check if an effect was just started or stopped */
>  		i = data[1] & 0x7f;
> -		if (data[1] & 0x80) {
> -			if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) {
> -				/* Report play event */
> -				input_report_ff_status(dev, i, FF_STATUS_PLAYING);
> +		if (i < IFORCE_EFFECTS_MAX) {
> +			unsigned long *flags = iforce->core_effects[i].flags;
> +
> +			if (data[1] & 0x80) {
> +				if (!test_and_set_bit(FF_CORE_IS_PLAYED, flags)) {
> +					/* Report play event */
> +					input_report_ff_status(dev, i, FF_STATUS_PLAYING);
> +				}
> +			} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, flags)) {
> +				/* Report stop event */
> +				input_report_ff_status(dev, i, FF_STATUS_STOPPED);
>  			}
> -		} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) {
> -			/* Report stop event */
> -			input_report_ff_status(dev, i, FF_STATUS_STOPPED);
>  		}
>  
>  		for (j = 3; j < len; j += 2)

[Severity: Critical]
This is a pre-existing issue, but was not introduced by the patch under review.

Could a zero-length USB packet cause an integer underflow that triggers a
massive out-of-bounds read in this loop?

Looking at iforce_usb_irq() in drivers/input/joystick/iforce/iforce-usb.c:

    iforce_process_packet(iforce, iforce_usb->data_in[0],
                  iforce_usb->data_in + 1, urb->actual_length - 1);

If urb->actual_length is 0, the subtraction underflows to a massive positive
unsigned value, which is passed as len.

If the first byte evaluates to a status report (packet ID 0x02), this loop
would execute against the underflowed len. Could this iterate billions of
times, repeatedly executing mark_core_as_ready() and causing uncontrolled
memory reads until an unmapped page is hit?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-b4-disp-4828d263-v1-1-02320e1a89dd@proton.me?part=1