Re: [PATCH] HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] An embedded struct member (which is not cacheline-aligned) is passed to an I2C transfer explicitly marked with I2C_M_DMA_SAFE, causing memory corruption if the adapter attempts direct DMA mapping.
--

commit 4324d522e00df3b4f32a9d44f12c88ed0a6abf38
Author: Youth Cao <cocoh2os08@gmail.com>

HID: i2c-hid: Add i2c-hid-quirk-bad-input-size quirk for 0911:5288 device

This commit adds the I2C_HID_QUIRK_BAD_INPUT_SIZE quirk option to the
existing Hantick 5288 quirk entry. This suppresses a kernel log flood
caused by incomplete reports from the Hynitron CST128-A touchpad controller.

> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 0e725a0f0abee..776dd14feba79 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -123,7 +123,7 @@ static const struct i2c_hid_quirks {
>  	__u32 quirks;
>  } i2c_hid_quirks[] = {
>  	{ I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
> -		I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
> +		I2C_HID_QUIRK_NO_IRQ_AFTER_RESET | I2C_HID_QUIRK_BAD_INPUT_SIZE },
>  	{ I2C_VENDOR_ID_ITE, I2C_DEVICE_ID_ITE_VOYO_WINPAD_A15,
>  		I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
>  	{ I2C_VENDOR_ID_RAYDIUM, I2C_PRODUCT_ID_RAYDIUM_3118,

[Severity: High]
This is a pre-existing issue, but I noticed a potential memory corruption
in how I2C HID devices are probed.

During device probe, i2c_hid_fetch_hid_descriptor() calls
i2c_hid_read_register() and passes the embedded struct member &ihid->hdesc
as the receive buffer:

drivers/hid/i2c-hid/i2c-hid-core.c:i2c_hid_fetch_hid_descriptor() {
	...
		error = i2c_hid_read_register(ihid,
					      ihid->wHIDDescRegister,
					      &ihid->hdesc,
					      sizeof(ihid->hdesc));
	...
}

This buffer is eventually passed to i2c_hid_xfer(), which explicitly sets the
I2C_M_DMA_SAFE flag on the message:

drivers/hid/i2c-hid/i2c-hid-core.c:i2c_hid_xfer() {
	...
	if (recv_len) {
		msgs[n].addr = client->addr;
		msgs[n].flags = (client->flags & I2C_M_TEN) |
				I2C_M_RD | I2C_M_DMA_SAFE;
		msgs[n].len = recv_len;
		msgs[n].buf = recv_buf;
		n++;
	}
	...
}

Since &ihid->hdesc is an embedded struct member and not cacheline-aligned,
explicitly marking it as I2C_M_DMA_SAFE bypasses the I2C core's bounce
buffering.

Could this cause memory corruption if the adapter attempts direct DMA mapping,
flushing or invalidating the shared cacheline and corrupting adjacent members
(like the client and hid pointers in struct i2c_hid)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903161444.786-1-cocoh2os08@gmail.com?part=1