Re: [PATCH v2 06/15] HID: ft260: i2c: reduce bus-error message severity

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] HID: ft260: use-after-free of dev in devres-managed gpio_chip on remove
--

commit 1fae4f26d8271d00c6ed7c7d5f16ef4ae51d0f21
Author: Michael Zaidman <michael.zaidman@gmail.com>

HID: ft260: i2c: reduce bus-error message severity

This commit lowers the log level of I2C bus error messages in
ft260_xfer_status(), ft260_i2c_write(), and ft260_smbus_write() from
hid_err() to ft260_dbg() to avoid spamming dmesg during bus scans, while
keeping hid_err() in ft260_hid_output_report_check_status() for actual HID
transport failures.

> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> index d2c5c9ed79276..6f8d729387025 100644
> --- a/drivers/hid/hid-ft260.c
> +++ b/drivers/hid/hid-ft260.c
> @@ -575,7 +575,7 @@ static int ft260_xfer_status(struct ft260_device *dev, u8 bus_busy)
>  	 * to 1, bit 1 is also set to 1.
>  	 */
>  	if (report.bus_status & FT260_I2C_STATUS_ERROR) {
> -		hid_err(hdev, "i2c bus error: %#02x\n", report.bus_status);
> +		ft260_dbg("i2c bus error: %#02x\n", report.bus_status);
>  		return -EIO;
>  	}

[Severity: High]
As reported by Sashiko on v1 [1], in drivers/hid/hid-ft260.c, ft260_probe()
allocates dev manually with kzalloc_obj(), while ft260_gpio_init() registers
the GPIO chip via devres with dev as its private data:

drivers/hid/hid-ft260.c:ft260_gpio_init() {
	...
	ret = devm_gpiochip_add_data(&hdev->dev, dev->gc, dev);
	if (ret < 0)
		hid_err(hdev, "cannot add GPIO chip %d\n", ret);
}

During unbind, hid_device_remove() calls ft260_remove() before releasing
hdev->dev's devres group via devres_release_group():

drivers/hid/hid-ft260.c:ft260_remove() {
	...
	hid_hw_close(hdev);
	hid_hw_stop(hdev);

	if (dev->iface_type == FT260_IFACE_UART)
		ft260_uart_port_put(dev);
	else
		kfree(dev);
}

Similarly, if sysfs_create_group() fails after ft260_gpio_init() in
ft260_i2c_probe() or ft260_uart_probe(), ft260_probe() frees dev before
__hid_device_probe() releases the devres group.

Because dev->gc remains registered until devres_release_group() runs, can a
concurrent GPIO callback such as ft260_gpio_get(), ft260_gpio_set(),
ft260_gpio_direction_input(), ft260_gpio_direction_output(), or
ft260_gpio_get_direction() obtain the freed dev pointer via
gpiochip_get_data(gc) and trigger a use-after-free?

[1] https://lore.kernel.org/r/20260822213941.98882-7-michael.zaidman@gmail.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030223637.86907-1-michael.zaidman@gmail.com?part=6