Re: [PATCH] HID: wacom: handle kmemdup failure in Bluetooth IRQ path

[Jason Gerecke]

On Fri, Jun 5, 2026 at 9:04 PM Ruoyu Wang <ruoyuw560@xxxxxxxxx> wrote:
>
> wacom_intuos_bt_irq() duplicates the input report with kmemdup() and then
> uses data[0] to dispatch the report type. If the allocation fails, the
> switch statement dereferences a NULL pointer.
>
> Handle allocation failure by dropping the report. This keeps the
> interrupt path from dereferencing a NULL buffer while preserving the
> existing return convention for ignored or malformed reports.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@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 da1f0ea85625d..c42af15e7dba0 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1206,6 +1206,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 (!data)
> +               return 0;
> +

Reviewed-by: Jason Gerecke <jason.gerecke@xxxxxxxxx>

Though, I think we should also (or instead?) entertain a change that
does away with the kmemdup entirely... Replacing this kmemdup and the
memcpy in wacom_intuos_bt_process_data with some simple pointer
manipulation should have the same effect with less work.

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