Re: [PATCH 4/5] HID: wacom: check the input device in wacom_intuos_bt_irq()

[Jason Gerecke]

On Sat, Sep 26, 2026 at 9:12 PM Jinmo Yang <jinmo44.yang@xxxxxxxxx> wrote:
>
> wacom_intuos_bt_irq() reaches for wacom->pen_input three ways without
> checking it: two dev_warn() calls on the short-report paths, a dev_dbg()
> on the unknown-report path, and input_sync(wacom->pen_input) inside
> wacom_intuos_bt_process_data(), which is called only from here. That last
> one is the odd one out, because the pad_input sync two lines below it is
> guarded:
>
>         input_sync(wacom->pen_input);
>         if (wacom->pad_input)
>                 input_sync(wacom->pad_input);
>
> An interface that declares no pen leaves the pointer NULL on a fully
> successful probe, as described in "HID: wacom: check the input device in
> the shared report helpers".
>
> Reproduced on linux-next 20260925 (x86_64, KASAN) with bus BUS_BLUETOOTH,
> vendor 0x056a product 0x00BD (INTUOS4WL):
>
>   BUG: KASAN: null-ptr-deref in range [0x258-0x25f]
>   RIP: 0010:wacom_wac_irq.cold+0x8f/0x16a
>    wacom_raw_event+0x68f/0xb60
>    __hid_input_report+0x398/0x4d0
>    uhid_char_write+0xa99/0xfc0
>
> One check at function entry covers all of them. It is safe to bail out
> there: this handler only runs for INTUOS4WL, and
> wacom_setup_device_quirks() only adds WACOM_DEVICETYPE_PAD for that
> range of types when WACOM_DEVICETYPE_PEN is already set, so a NULL
> pen_input implies a NULL pad_input and there is nothing the function can
> report. Every path that reaches the battery notification passes through
> wacom_intuos_bt_process_data() first, so no reachable work is lost.
>

Similar to patch 2/5, INTUOS4WL is a case where all hardware of this
type should have both pen and pad on a single interface. The existing
explicit check for a non-NULL pad does not imply that pen-only devices
of this type exist. As you describe here, there are no situations
where only the pad would exist, and there is also no situation in
which only the pen would exist (the WACOM_DEVICETYPE_PEN will already
be set, as described). A check for both pen and touch pointer validity
can be performed at the beginning of both wacom_setup_device_quirks
and wacom_intuos_bt_process_data.

> Fixes: 2a6cdbdd4cc0 ("HID: wacom: Introduce new 'touch_input' device")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Jinmo Yang <jinmo44.yang@xxxxxxxxx>
> ---
>  drivers/hid/wacom_wac.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 48a58a6672c2..11544adb74f5 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1237,6 +1237,9 @@ static int wacom_intuos_bt_irq(struct wacom_wac *wacom, size_t len)
>         int i = 1;
>         unsigned power_raw, battery_capacity, bat_charging, ps_connected;
>
> +       if (!wacom->pen_input)
> +               return 0;
> +

As with patch 1, each of these checks is for an unusual error
condition so a dev_warn_once or hid_warn_once before returning is
suggested.

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....


>         switch (data[0]) {
>         case 0x04:
>                 if (len < 32) {
> --
> 2.53.0
>
>