usb: ljca: possible stack overflow in ljca_enumerate_gpio()

usb: ljca: possible stack overflow in ljca_enumerate_gpio()

[Maoyi Xie]

Hi all,

I think ljca_enumerate_gpio() in drivers/usb/misc/usb-ljca.c can write past
the valid_pin array on the stack. I would appreciate it if you could take a
look.

The GPIO descriptor comes from the device. It carries pins_per_bank and
bank_num. The function has a small fixed array on the stack.

	u32 valid_pin[LJCA_MAX_GPIO_NUM / BITS_PER_TYPE(u32)];

That is two u32 entries. Two checks run before the loop. One matches the
reply length against the descriptor.

	if (ret != struct_size(desc, bank_desc, desc->bank_num))
		return -EINVAL;

The other bounds the pin product.

	gpio_num = desc->pins_per_bank * desc->bank_num;
	if (gpio_num > LJCA_MAX_GPIO_NUM)
		return -EINVAL;

Then the loop walks bank_num.

	for (i = 0; i < desc->bank_num; i++)
		valid_pin[i] = get_unaligned_le32(&desc->bank_desc[i].valid_pins);

Nothing checks bank_num against the size of valid_pin. The reply is capped at
60 bytes, so the struct_size check limits bank_num to 9. A device that reports
bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and
the reply is 56 bytes. The loop then writes nine u32 into the two entry array,
seven past the end.

I reproduced the write on 7.1-rc7 by running the same loop over the same stack
array with a bank_num of 9.

  BUG: KASAN: stack-out-of-bounds in ljca_enumerate_gpio
  Write of size 4 ... [32, 40) 'valid_pin'

The fix I tried rejects a bank_num too large for valid_pin before the loop.

	 	if (gpio_num > LJCA_MAX_GPIO_NUM)
	 		return -EINVAL;
	+
	+	if (desc->bank_num > ARRAY_SIZE(valid_pin))
	+		return -EINVAL;

This needs a malicious or broken LJCA device, not a remote attacker. It still
looks like a stack overflow to me. Does this look right, and is that the place
to bound it? Happy to send a proper patch once you confirm.

Thanks,
Maoyi
https://maoyixie.com/

Re: usb: ljca: possible stack overflow in ljca_enumerate_gpio()

[Greg Kroah-Hartman]

On Wed, Jun 17, 2026 at 06:42:01PM +0800, Maoyi Xie wrote:
> Hi all,
> 
> I think ljca_enumerate_gpio() in drivers/usb/misc/usb-ljca.c can write past
> the valid_pin array on the stack. I would appreciate it if you could take a
> look.
> 
> The GPIO descriptor comes from the device. It carries pins_per_bank and
> bank_num. The function has a small fixed array on the stack.
> 
> 	u32 valid_pin[LJCA_MAX_GPIO_NUM / BITS_PER_TYPE(u32)];
> 
> That is two u32 entries. Two checks run before the loop. One matches the
> reply length against the descriptor.
> 
> 	if (ret != struct_size(desc, bank_desc, desc->bank_num))
> 		return -EINVAL;
> 
> The other bounds the pin product.
> 
> 	gpio_num = desc->pins_per_bank * desc->bank_num;
> 	if (gpio_num > LJCA_MAX_GPIO_NUM)
> 		return -EINVAL;
> 
> Then the loop walks bank_num.
> 
> 	for (i = 0; i < desc->bank_num; i++)
> 		valid_pin[i] = get_unaligned_le32(&desc->bank_desc[i].valid_pins);
> 
> Nothing checks bank_num against the size of valid_pin. The reply is capped at
> 60 bytes, so the struct_size check limits bank_num to 9. A device that reports
> bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and
> the reply is 56 bytes. The loop then writes nine u32 into the two entry array,
> seven past the end.
> 
> I reproduced the write on 7.1-rc7 by running the same loop over the same stack
> array with a bank_num of 9.
> 
>   BUG: KASAN: stack-out-of-bounds in ljca_enumerate_gpio
>   Write of size 4 ... [32, 40) 'valid_pin'
> 
> The fix I tried rejects a bank_num too large for valid_pin before the loop.
> 
> 	 	if (gpio_num > LJCA_MAX_GPIO_NUM)
> 	 		return -EINVAL;
> 	+
> 	+	if (desc->bank_num > ARRAY_SIZE(valid_pin))
> 	+		return -EINVAL;
> 
> This needs a malicious or broken LJCA device, not a remote attacker. It still
> looks like a stack overflow to me. Does this look right, and is that the place
> to bound it? Happy to send a proper patch once you confirm.

We trust the hardware to do the right thing once a driver is bound to a
device.  That being said, making checks like this to prevent obviously
malicious or broken devices from crashing the kernel are almost always
accepted, so just make up a patch and submit it.

thanks,

greg k-h