Re: [PATCH v3 3/6] HID: wacom: add NULL pad_input guard to wacom_intuos_pad()

[Jason Gerecke]

On Sun, Oct 18, 2026 at 5:49 AM Jinmo Yang <jinmo44.yang@xxxxxxxxx> wrote:
>
> wacom_intuos_pad() uses wacom->pad_input throughout, but pad_input can
> be NULL when wacom_setup_pad_input_capabilities() returns -ENODEV during
> a successful probe.
>
> Place the guard after the data[0] report-ID check and return 1 so the
> report is consumed. Returning 0 would let the caller fall through to
> wacom_intuos_inout(), which would misparse the pad packet as a pen
> event.
>

The other intuos functions (wacom_intuos_inout() and
wacom_intuos_general()) reference pen_input and a rough evaluation by
eye makes me think that they are susceptible to the same kind of
issue. I feel like it would make sense to add a check for non-null
pen_input at the top of wacom_intuos_irq() to protect its helpers, in
addition to the pad_input check you add in this patch.

> Fixes: 10059cdc0ad0 ("Input: wacom - split out the pad device for Intuos/Cintiq")
> Signed-off-by: Jinmo Yang <jinmo44.yang@xxxxxxxxx>
> Co-Authored-By: Claude Opus 4.6 <noreply@xxxxxxxxxxxxx>
> ---
>  drivers/hid/wacom_wac.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index bec8dbec5bc3..65829de86363 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -581,6 +581,12 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
>               data[0] == WACOM_REPORT_CINTIQPAD))
>                 return 0;
>
> +       if (!input) {
> +               dev_warn_once(&container_of(wacom, struct wacom, wacom_wac)->hdev->dev,
> +                             "%s: pad_input is NULL\n", __func__);
> +               return 1; /* consume the report to prevent fall-through */
> +       }
> +

Returning a non-zero value will trigger an eventual input_sync() at
the bottom of wacom_wac_irq(). Realistically this shouldn't matter
since we would never expect a null pad in normal operation (so these
spurious syncs are unlikely), but it still kinda pokes me the wrong
way. I feel like update wacom_intuos_pad should be updated to follow
the same return convention as the other intuos_* functions where
wacom_intuos_irq() has a "return result -1" to allow functions to
signal "handled, but don't sync".

Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....




>         if (features->type >= INTUOS4S && features->type <= INTUOS4L) {
>                 buttons = (data[3] << 1) | (data[2] & 0x01);
>                 ring1 = data[1];
> --
> 2.53.0
>
>