Re: [PATCH 3/4] HID: wacom: validate report length for DTUS handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The global `if (len < 7)` check in `wacom_wac_irq()` for DTUS/DTUSX devices drops valid short reports, breaking the DTUSPAD (pad buttons) functionality.
- [High] Incomplete fix leaving other device types vulnerable to slab-out-of-bounds reads.
- [High] NULL pointer dereference in `wacom_dtus_irq` for DTUSX devices.
--

commit bbe438798c1e7006b14d3fc0a92585f47e3776e2
Author: Jinmo Yang <jinmo44.yang@gmail.com>

HID: wacom: validate report length for DTUS handler

This commit adds a minimum length check in wacom_wac_irq() for DTUS and DTUSX
devices before dispatching to wacom_dtus_irq() to prevent out-of-bounds reads.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 873d58a6d5a3b..269e8318f79af 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3479,6 +3479,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  
>  	case DTUS:
>  	case DTUSX:
> +		if (len < 7)
> +			return;

Does this global length check drop valid short reports for pad buttons?

Looking at wacom_dtus_irq(), it processes two different reports:
WACOM_REPORT_DTUS which accesses up to data[6], and WACOM_REPORT_DTUSPAD
which only accesses data[0] and data[1].

If the pad report is sent as a 2-byte transfer, this check will drop it before
it reaches the handler, breaking the ExpressKeys functionality.

Should the validation first check the report ID (ensuring len >= 1) and then
enforce the minimum length specific to the report type?

Also, while this patch adds a check for DTUS/DTUSX, does it leave other device
types vulnerable to similar out-of-bounds reads?

Other branches in wacom_wac_irq() such as PENPARTNER (which accesses up to
data[6]) and GRAPHIRE (which accesses up to data[7]) do not appear to have
length checks before calling their respective handlers.

Lastly, looking at wacom_dtus_irq(), it handles WACOM_REPORT_DTUSPAD by using
wacom->pad_input:

drivers/hid/wacom_wac.c:wacom_dtus_irq() {
	...
	} else if (data[0] == WACOM_REPORT_DTUSPAD) {
		input = wacom->pad_input;
		input_report_key(input, BTN_0, (data[1] & 0x01));
	...
}

Since DTUSX does not receive the WACOM_DEVICETYPE_PAD capability flag during
initialization, wacom->pad_input remains NULL.

If a spoofed DTUSX device sends a WACOM_REPORT_DTUSPAD report, does this cause
a NULL pointer dereference when calling input_report_key()?

>  		sync = wacom_dtus_irq(wacom_wac);
>  		break;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260517135215.2220117-1-jinmo44.yang@gmail.com?part=3