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

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

[Jinmo Yang]

wacom_intuos_pad() dereferences wacom->pad_input without a NULL check.
When a Wacom tablet is created via UHID with parameters that route
through wacom_bpt_irq() -> wacom_intuos_irq() -> wacom_intuos_pad(),
but probe did not allocate pad_input, the call to
wacom_report_numbered_buttons() passes a NULL input_dev, causing a
general protection fault in input_get_drvdata().

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

The bug was found by syzkaller and confirmed on a Pixel 9 Pro
(Android 16, kernel 6.1.124) where it causes an immediate kernel
panic and reboot via /dev/uhid without requiring root privileges:

  KP: Oops: Fatal exception: comm:wacom_27qhdt
  Reboot reason: 0xbaba - Kernel PANIC

Reproducer (unprivileged):
  open("/dev/uhid", O_RDWR)
  write(fd, UHID_CREATE2{vendor=0x056a, product=0x0020})
  write(fd, UHID_INPUT2{report_id=0x0c, size=10})

Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index da1f0ea85..251ddda3e 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -515,7 +515,6 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
 	struct wacom_features *features = &wacom->features;
 	unsigned char *data = wacom->data;
 	struct input_dev *input = wacom->pad_input;
-	int i;
 	int buttons = 0, nbuttons = features->numbered_buttons;
 	int keys = 0, nkeys = 0;
 	int ring1 = 0, ring2 = 0;
@@ -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;
 
 	/* pad packets. Works as a second tool and is always in prox */
 	if (!(data[0] == WACOM_REPORT_INTUOSPAD || data[0] == WACOM_REPORT_INTUOS5PAD ||
-- 
2.53.0

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

[Jinmo Yang]

wacom_intuos_pad() dereferences wacom->pad_input without a NULL check.
When a Wacom tablet is created via UHID with parameters that route
through wacom_bpt_irq() -> wacom_intuos_irq() -> wacom_intuos_pad(),
but probe did not allocate pad_input, the call to
wacom_report_numbered_buttons() passes a NULL input_dev, causing a
general protection fault in input_get_drvdata().

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

The bug was found by syzkaller on linux-next 7.1.0-rc4 (next-20260522):

  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000052
  KASAN: null-ptr-deref in range [0x0000000000000290-0x0000000000000297]
  RIP: 0010:input_get_drvdata include/linux/input.h:390 [inline]
  RIP: 0010:wacom_report_numbered_buttons+0x37/0x210 drivers/hid/wacom_wac.c:4210
  Call Trace:
   wacom_intuos_pad drivers/hid/wacom_wac.c:643 [inline]
   wacom_intuos_irq+0x29a/0x32b0 drivers/hid/wacom_wac.c:1042
   wacom_bpt_irq drivers/hid/wacom_wac.c:3275 [inline]
   wacom_wac_irq+0x12ed/0xaef0 drivers/hid/wacom_wac.c:3545
   wacom_raw_event+0x677/0xa90 drivers/hid/wacom_sys.c:184
   __hid_input_report.constprop.0+0x39a/0x4d0 drivers/hid/hid-core.c:2161
   uhid_dev_input2 drivers/hid/uhid.c:618 [inline]
   uhid_char_write+0xa8a/0xfa0 drivers/hid/uhid.c:776

Also confirmed on a Pixel 9 Pro (Android 16, kernel 6.1.124) where
it causes an immediate kernel panic and reboot via /dev/uhid without
requiring root privileges:

  KP: Oops: Fatal exception: comm:wacom_27qhdt
  Reboot reason: 0xbaba - Kernel PANIC

Reproducer (unprivileged):
  open("/dev/uhid", O_RDWR)
  write(fd, UHID_CREATE2{vendor=0x056a, product=0x0020})
  write(fd, UHID_INPUT2{report_id=0x0c, size=10})

Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index da1f0ea85..251ddda3e 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -515,7 +515,6 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
 	struct wacom_features *features = &wacom->features;
 	unsigned char *data = wacom->data;
 	struct input_dev *input = wacom->pad_input;
-	int i;
 	int buttons = 0, nbuttons = features->numbered_buttons;
 	int keys = 0, nkeys = 0;
 	int ring1 = 0, ring2 = 0;
@@ -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;
 
 	/* pad packets. Works as a second tool and is always in prox */
 	if (!(data[0] == WACOM_REPORT_INTUOSPAD || data[0] == WACOM_REPORT_INTUOS5PAD ||
-- 
2.53.0

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

[sashiko-bot]

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

New issues:
- [High] The patch's early return in `wacom_intuos_pad()` causes valid pad reports to fall through to pen handlers when `pad_input` is NULL.

Pre-existing issues:
- [High] The patch addresses a NULL pointer dereference for `pad_input` but completely misses identical vulnerabilities for `pen_input` and `touch_input`.
- [High] Concurrent execution of `wacom_mode_change_work()` and `wacom_raw_event()` can lead to a Use-After-Free of input devices.
- [High] A dangling pointer in `wacom->shared->touch_input` leads to Use-After-Free when the Touch interface unbinds while the Pad interface remains active.
--

commit e74a772fd06994c14eb8d49710acd3ad8740df1f
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, preventing a general protection fault.

> 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
> @@ -515,7 +515,6 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
>  	struct wacom_features *features = &wacom->features;
>  	unsigned char *data = wacom->data;
>  	struct input_dev *input = wacom->pad_input;
> -	int i;
>  	int buttons = 0, nbuttons = features->numbered_buttons;
>  	int keys = 0, nkeys = 0;
>  	int ring1 = 0, ring2 = 0;
> @@ -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 allow the event to fall through to other handlers?

wacom_intuos_irq() relies on a non-zero return to halt processing. If this
returns 0, a crafted pad packet might fall through to wacom_intuos_inout().

Since wacom_intuos_inout() only checks data[1] and not the report ID, it
could misinterpret a pad report as a pen proximity event. For example, if
data[1] == 0x80, could it trigger wacom_exit_report() and either inject a
spurious pen exit event or cause a NULL pointer dereference if pen_input
is also NULL?

Would it be better to place this check after verifying the report ID, and
return 1 to securely drop the packet?

[Severity: High]
This isn't a bug introduced by this patch, but does the same NULL pointer
vulnerability exist for pen_input and touch_input?

A crafted UHID descriptor can omit pen and touch capabilities, leaving
wacom->pen_input and wacom->touch_input as NULL.

If valid pen or touch packets are subsequently received, handlers like
wacom_exit_report(), wacom_intuos_general(), and wacom_bpt3_touch_msg()
appear to blindly dereference these NULL pointers.

[Severity: High]
This is a pre-existing issue, but can concurrent execution of
wacom_mode_change_work() and wacom_raw_event() lead to a use-after-free
of the input devices?

wacom_mode_change_work() frees input devices asynchronously via
wacom_release_resources() and devres_release_group(), without holding the
lock that serializes input report processing.

Concurrently, a raw input report could enter wacom_intuos_pad(), read the
wacom->pad_input pointer, successfully pass this new if (!input) check,
and then access the input device right after it gets freed.

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

[Severity: High]
This is a pre-existing issue, but can wacom->shared->touch_input become a
dangling pointer if the touch interface unbinds while the pad interface
remains active?

When a touch interface is unbound, its input devices are freed via
devres_release_group(), but wacom_remove_shared_data() does not appear to
set wacom->shared->touch_input to NULL.

If a pad event is received later, the pad event handler invokes
input_report_switch() and input_sync() on the dangling pointer:

    if (wacom->shared && wacom->shared->touch_input) {
        input_report_switch(wacom->shared->touch_input,
                            SW_MUTE_DEVICE,
                            !wacom->shared->is_touch_on);
        input_sync(wacom->shared->touch_input);
    }

Could this result in a use-after-free?

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

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

[sashiko-bot]

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