Re: [PATCH] HID: wacom: fix NULL pointer dereference in wacom_intuos_pad()

[sashiko-bot@kernel.org]

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

New issues:
- [High] The added early return `if (!input) return 0;` in `wacom_intuos_pad()` fails to consume unhandled pad packets, causing them to fall through and be misinterpreted as pen events.

Pre-existing issues:
- [High] Identical NULL pointer dereference vulnerabilities exist for `pen_input` and `touch_input` in other event handlers.
--

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

HID: wacom: fix NULL pointer dereference in wacom_intuos_pad()

This commit adds a NULL check for pad_input at the top of wacom_intuos_pad()
to bail out early when the pad input device was not set up. This prevents
a general protection fault in input_get_drvdata() when a Wacom tablet is
created via UHID with missing interfaces.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625d..251ddda3ecb3d 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -523,6 +522,10 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
>  	bool prox = false;
>  	bool wrench = false, keyboard = false, mute_touch = false, menu = false,
>  	     info = false;
> +	int i;
> +
> +	if (!input)
> +		return 0;

[Severity: High]
Does returning 0 here instead of 1 when input is NULL cause the pad packet
to be treated as unhandled?

If wacom_intuos_irq() receives a 0, it falls through to wacom_intuos_inout().
Since wacom_intuos_inout() does not validate the report ID in data[0],
could a pad packet coincidentally matching proximity masks be incorrectly
processed as a pen event, causing spurious events and state corruption?

Should the !input check be moved after the data[0] check, and return 1
to consume and discard the unhandled packet?

[Severity: High]
This is a pre-existing issue, but are there identical NULL pointer dereference
vulnerabilities for wacom->pen_input and wacom->touch_input?

If an attacker uses /dev/uhid to create a virtual device without PEN or TOUCH
collections, pen_input and touch_input remain NULL.

If packets for these missing interfaces are sent, will handlers like
wacom_bpt_touch(), wacom_bpt_pen(), or wacom_intuos_inout() unconditionally
dereference these NULL pointers during input_event() calls or when reporting
out-of-proximity events?

>  
>  	/* pad packets. Works as a second tool and is always in prox */
>  	if (!(data[0] == WACOM_REPORT_INTUOSPAD || data[0] == WACOM_REPORT_INTUOS5PAD ||
>  	      data[0] == WACOM_REPORT_CINTIQPAD))
>  		return 0;

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