[PATCH 0/4] HID: wacom: add report length validation in irq handlers

[PATCH 0/4] HID: wacom: add report length validation in irq handlers

[Jinmo Yang]

Several wacom IRQ handler sub-functions access fixed offsets in the raw
HID report buffer without validating the buffer length. wacom_wac_irq()
receives the length from wacom_raw_event() but does not validate it
before dispatching to the sub-functions, which do not receive the length
parameter.

A malicious USB device can declare a small HID report in its descriptor
and send a matching short report that passes the HID core size check
(csize >= rsize), but the driver assumes a full-size hardware report
layout, leading to slab-out-of-bounds reads.

Note: this is not mitigated by the recent HID core bounds checking
series which validates actual_size >= declared_size. An attacker
controls both the descriptor (declared size) and the sent data (actual
size), so the core check passes. Driver-level validation against the
expected hardware report layout is still necessary.

Tested with KASAN on Linux 7.1-rc3 (slab-out-of-bounds confirmed) and
verified kernel panic on a production device via uhid.

Jinmo Yang (4):
  HID: wacom: validate report length for PL and PTU handlers
  HID: wacom: validate report length for DTU handler
  HID: wacom: validate report length for DTUS handler
  HID: wacom: validate report length for 24HDT and 27QHDT handlers

 drivers/hid/wacom_wac.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.53.0

[PATCH 1/4] HID: wacom: validate report length for PL and PTU handlers

[Jinmo Yang]

wacom_pl_irq() and wacom_ptu_irq() access fixed offsets up to data[7]
in the raw HID report buffer without validating the buffer length.
These sub-functions are called from wacom_wac_irq() which receives the
length parameter but does not pass it to the handlers.

A malicious USB device can declare a small HID report in its descriptor
and send a matching short report that passes the HID core size check
(csize >= rsize), but the driver assumes a full-size hardware report
layout, leading to slab-out-of-bounds reads.

Add minimum length checks in wacom_wac_irq() before dispatching to
wacom_pl_irq() and wacom_ptu_irq().

Fixes: 4104d13fe019 ("Input: move USB tablets under drivers/input/tablet")
Cc: stable@vger.kernel.org
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index da1f0ea85..6d06842b6 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3453,6 +3453,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 		break;
 
 	case PL:
+		if (len < 8)
+			return;
 		sync = wacom_pl_irq(wacom_wac);
 		break;
 
@@ -3464,6 +3466,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 		break;
 
 	case PTU:
+		if (len < 8)
+			return;
 		sync = wacom_ptu_irq(wacom_wac);
 		break;
 
-- 
2.53.0

Re: [PATCH 1/4] HID: wacom: validate report length for PL and PTU handlers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete Fix / Unhandled OOB Reads for Multiple Device Types
--

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

HID: wacom: validate report length for PL and PTU handlers

This commit adds minimum length checks before dispatching HID reports to
the PL and PTU handlers. This prevents slab-out-of-bounds reads when a
malicious device sends an artificially small report.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625d..6d06842b64080 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3453,6 +3453,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  		break;
>  
>  	case PL:
> +		if (len < 8)
> +			return;
>  		sync = wacom_pl_irq(wacom_wac);
>  		break;
>  

[ ... ]

> @@ -3464,6 +3466,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  		break;
>  
>  	case PTU:
> +		if (len < 8)
> +			return;
>  		sync = wacom_ptu_irq(wacom_wac);
>  		break;
>  

While this successfully prevents out-of-bounds reads for PL and PTU devices,
do other handlers called from wacom_wac_irq() remain vulnerable to the same
issue?

For example, wacom_graphire_irq() unconditionally accesses data[8] for
WACOM_MO:

wacom_wac_irq()
  wacom_graphire_irq()
    case WACOM_MO:
      prox = (data[7] & 0xf8) || data[8];

Similarly, wacom_remote_irq() ignores its len argument and accesses up to
data[12], and wacom_intuos_pro2_bt_battery() can access data[284].

If a device spoofing these other types sends an undersized report, could it
bypass the checks added here and still trigger a slab-out-of-bounds read?

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

[PATCH 2/4] HID: wacom: validate report length for DTU handler

[Jinmo Yang]

wacom_dtu_irq() accesses fixed offsets up to data[7] in the raw HID
report buffer without validating the buffer length. This sub-function
is called from wacom_wac_irq() which receives the length parameter but
does not pass it to the handler.

A malicious USB device can declare a small HID report in its descriptor
and send a matching short report that passes the HID core size check
(csize >= rsize), but the driver assumes a full-size hardware report
layout, leading to slab-out-of-bounds reads.

Add a minimum length check in wacom_wac_irq() before dispatching to
wacom_dtu_irq().

Fixes: c8f2edc56acf ("Input: wacom - add support for DTU2231 and DTU1631")
Cc: stable@vger.kernel.org
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 6d06842b6..873d58a6d 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3472,6 +3472,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 		break;
 
 	case DTU:
+		if (len < 8)
+			return;
 		sync = wacom_dtu_irq(wacom_wac);
 		break;
 
-- 
2.53.0

Re: [PATCH 2/4] HID: wacom: validate report length for DTU handler

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete fix for slab-out-of-bounds read vulnerability. The patch correctly validates the buffer length for the DTU device handler, but leaves numerous other device handlers in the same function completely unpatched and vulnerable to the identical attack vector.
--

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

HID: wacom: validate report length for DTU handler

wacom_dtu_irq() accesses fixed offsets up to data[7] in the raw HID
report buffer without validating the buffer length. This commit adds
a minimum length check in wacom_wac_irq() before dispatching to
wacom_dtu_irq() to prevent slab-out-of-bounds reads.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 6d06842b64080..873d58a6d5a3b 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3472,6 +3472,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  		break;
>  
>  	case DTU:
> +		if (len < 8)
> +			return;
>  		sync = wacom_dtu_irq(wacom_wac);
>  		break;

Could this same regression occur in the other device handlers called
from wacom_wac_irq()?

For example, cases like PENPARTNER, GRAPHIRE, and INTUOS also dispatch
to their respective handlers without checking len:

	switch (wacom_wac->features.type) {
	case PENPARTNER:
		sync = wacom_penpartner_irq(wacom_wac);
		break;
	[ ... ]
	case GRAPHIRE:
	[ ... ]
		sync = wacom_graphire_irq(wacom_wac);
		break;
	[ ... ]
	case INTUOS:
	[ ... ]
		sync = wacom_intuos_irq(wacom_wac);
		break;

Since these sub-handlers do not receive the len parameter, an attacker
spoofing the VID/PID of a PENPARTNER or INTUOS device might be able to
send a short report and trigger a similar out-of-bounds read regression.

Should length validations be added for the remaining device types to
ensure all handlers are protected?

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

[PATCH 3/4] HID: wacom: validate report length for DTUS handler

[Jinmo Yang]

wacom_dtus_irq() accesses fixed offsets up to data[6] in the raw HID
report buffer without validating the buffer length. This sub-function
is called from wacom_wac_irq() which receives the length parameter but
does not pass it to the handler.

A malicious USB device can declare a small HID report in its descriptor
and send a matching short report that passes the HID core size check
(csize >= rsize), but the driver assumes a full-size hardware report
layout, leading to slab-out-of-bounds reads.

Add a minimum length check in wacom_wac_irq() before dispatching to
wacom_dtus_irq().

Fixes: 497ab1f290a2 ("Input: wacom - add support for DTU-1031")
Cc: stable@vger.kernel.org
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 873d58a6d..269e8318f 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3479,6 +3479,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 
 	case DTUS:
 	case DTUSX:
+		if (len < 7)
+			return;
 		sync = wacom_dtus_irq(wacom_wac);
 		break;
 
-- 
2.53.0

Re: [PATCH 3/4] HID: wacom: validate report length for DTUS handler

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The global `if (len < 7)` check in `wacom_wac_irq()` for DTUS/DTUSX devices drops valid short reports, breaking the DTUSPAD (pad buttons) functionality.
- [High] Incomplete fix leaving other device types vulnerable to slab-out-of-bounds reads.
- [High] NULL pointer dereference in `wacom_dtus_irq` for DTUSX devices.
--

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

HID: wacom: validate report length for DTUS handler

This commit adds a minimum length check in wacom_wac_irq() for DTUS and DTUSX
devices before dispatching to wacom_dtus_irq() to prevent out-of-bounds reads.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 873d58a6d5a3b..269e8318f79af 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3479,6 +3479,8 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  
>  	case DTUS:
>  	case DTUSX:
> +		if (len < 7)
> +			return;

Does this global length check drop valid short reports for pad buttons?

Looking at wacom_dtus_irq(), it processes two different reports:
WACOM_REPORT_DTUS which accesses up to data[6], and WACOM_REPORT_DTUSPAD
which only accesses data[0] and data[1].

If the pad report is sent as a 2-byte transfer, this check will drop it before
it reaches the handler, breaking the ExpressKeys functionality.

Should the validation first check the report ID (ensuring len >= 1) and then
enforce the minimum length specific to the report type?

Also, while this patch adds a check for DTUS/DTUSX, does it leave other device
types vulnerable to similar out-of-bounds reads?

Other branches in wacom_wac_irq() such as PENPARTNER (which accesses up to
data[6]) and GRAPHIRE (which accesses up to data[7]) do not appear to have
length checks before calling their respective handlers.

Lastly, looking at wacom_dtus_irq(), it handles WACOM_REPORT_DTUSPAD by using
wacom->pad_input:

drivers/hid/wacom_wac.c:wacom_dtus_irq() {
	...
	} else if (data[0] == WACOM_REPORT_DTUSPAD) {
		input = wacom->pad_input;
		input_report_key(input, BTN_0, (data[1] & 0x01));
	...
}

Since DTUSX does not receive the WACOM_DEVICETYPE_PAD capability flag during
initialization, wacom->pad_input remains NULL.

If a spoofed DTUSX device sends a WACOM_REPORT_DTUSPAD report, does this cause
a NULL pointer dereference when calling input_report_key()?

>  		sync = wacom_dtus_irq(wacom_wac);
>  		break;
>

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

[PATCH 4/4] HID: wacom: validate report length for 24HDT and 27QHDT handlers

[Jinmo Yang]

wacom_24hdt_irq() accesses data[61] for WACOM_24HDT and data[63] for
WACOM_27QHDT in the raw HID report buffer without validating the buffer
length. This sub-function is called from wacom_wac_irq() which receives
the length parameter but does not pass it to the handler.

A malicious USB device can declare a small HID report in its descriptor
and send a matching short report that passes the HID core size check
(csize >= rsize), but the driver assumes a full-size hardware report
layout, leading to slab-out-of-bounds reads.

Add minimum length checks in wacom_wac_irq() before dispatching to
wacom_24hdt_irq() for both device types.

Fixes: b1e4279e4ef5 ("Input: wacom - add touch sensor support for Cintiq 24HD touch")
Cc: stable@vger.kernel.org
Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
---
 drivers/hid/wacom_wac.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 269e8318f..2fd1c4e80 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3509,7 +3509,14 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
 		break;
 
 	case WACOM_24HDT:
+		if (len < 62)
+			return;
+		sync = wacom_24hdt_irq(wacom_wac);
+		break;
+
 	case WACOM_27QHDT:
+		if (len < 64)
+			return;
 		sync = wacom_24hdt_irq(wacom_wac);
 		break;
 
-- 
2.53.0

Re: [PATCH 4/4] HID: wacom: validate report length for 24HDT and 27QHDT handlers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch provides an incomplete fix for out-of-bounds reads caused by short HID reports. It adds length checks for `WACOM_24HDT` and `WACOM_27QHDT`, but misses the exact same vulnerability in numerous other device handlers called by `wacom_wac_irq()`.
--

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

HID: wacom: validate report length for 24HDT and 27QHDT handlers

This commit adds length checks to wacom_wac_irq to prevent out-of-bounds
reads for WACOM_24HDT and WACOM_27QHDT devices when they receive short HID
reports.

> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 269e8318f79af..2fd1c4e80a72b 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3509,7 +3509,14 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>  		break;
>  
>  	case WACOM_24HDT:
> +		if (len < 62)
> +			return;
> +		sync = wacom_24hdt_irq(wacom_wac);
> +		break;
> +
>  	case WACOM_27QHDT:
> +		if (len < 64)
> +			return;
>  		sync = wacom_24hdt_irq(wacom_wac);
>  		break;

While this prevents out-of-bounds reads for WACOM_24HDT and WACOM_27QHDT,
are there other device handlers in this switch statement that also need
report length validation?

For example, handlers like INTUOSP2_BT, REMOTE, INTUOS, and PENPARTNER
appear to process reports without validating the buffer length.

Looking at wacom_intuos_pro2_bt_irq(), it receives the length but seems to
unconditionally call wacom_intuos_pro2_bt_pen():

wacom_wac_irq() -> wacom_intuos_pro2_bt_irq() -> wacom_intuos_pro2_bt_pen()

Does this allow wacom_intuos_pro2_bt_pen() to read up to data[107] without
validating the buffer size?

Similarly, does wacom_remote_status_irq() read up to data[30] to populate
remote serial numbers without checking the length?

Could a malicious device sending short reports still trigger regressions
like slab-out-of-bounds reads or information leaks to userspace through
these other handlers?

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