kernel/drivers/hid/wacom_wac.c, branch master

HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq

2026-03-09T18:34:12Z

The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received. Signed-off-by: Benoît Sevens Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Add a new Art Pen 2

2025-08-12T12:56:35Z

Signed-off-by: Ping Cheng Signed-off-by: Jiri Kosina

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37Z

Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

HID: wacom: Remove static WACOM_PKGLEN_MAX limit

2025-03-04T20:51:04Z

Rather than memcpy every packet that we receive from HID into our own local fixed-size array, we can just access the data directly through the original pointer. While we're at it, remove the few other places that assume a fixed maximum packet size and make them dynamic (in particular: temporary buffers created by the wacom_wac_queue_flush and wacom_intuos_bt_process_data functions; and the pen_fifo FIFO). To ensure pen_fifo allocation has access to the maximum used packet length, this commit also moves the function call to occur a little later in the probe process. Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: Wacom: Add PCI Wacom device support

2025-01-09T09:16:47Z

Add PCI device ID of wacom device into driver support list. Signed-off-by: Even Xu Tested-by: Tatsunosuke Tobita Reviewed-by: Ping Cheng Signed-off-by: Jiri Kosina

Merge branch 'for-6.13/wacom' into for-linus

2024-11-18T20:29:33Z

- Sanitization of BTN_TOOL_RUBBER handling (Jason Gerecke)

HID: wacom: Interpret tilt data from Intuos Pro BT as signed values

2024-11-06T14:56:35Z

The tilt data contained in the Bluetooth packets of an Intuos Pro are supposed to be interpreted as signed values. Simply casting the values to type `char` is not guaranteed to work since it is implementation- defined whether it is signed or unsigned. At least one user has noticed the data being reported incorrectly on their system. To ensure that the data is interpreted properly, we specifically cast to `signed char` instead. Link: https://github.com/linuxwacom/input-wacom/issues/445 Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") CC: stable@vger.kernel.org # 4.11+ Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Set eraser status when either 'Eraser' or 'Invert' usage is set

2024-10-18T10:48:35Z

Microsoft defines two slightly different behaviors for pens that are being used to erase. The first one, for pens that can be used while inverted specifies that both 'Invert' and 'Eraser' usages should be set while the pen is in contact and erasing. For pens that use an eraser button though, they specify that only the 'Eraser' usage should be set (while hovering, only the 'Invert' usage is to be set). We used our internal 'invert_state' flag to determine if a pen has an intent to erase (whether hovering or not). That flag was previously only depending on the 'Invert' usage, which was sufficient for the first type of pen (EMR) but not the second type (AES). This commit makes the flag depend on either usage being set, and also renames it to make its function more clear. This change should not normally have an impact on userspace due to both the existing driver and firmware design. The driver already only determines tool type based on the first event in an interaction (e.g. it will see the 'Invert' bit set when the eraser comes into prox and then report BTN_TOOL_RUBBER for the rest of the interaction, even if 'Invert' is cleared). AES firmware is also careful to send reports that work through a set of defined state transitions, even in the corner-case where the eraser button is pressed when the pen is already in contact with the display (Prox|Tip -> Prox -> 0 -> Invert -> Eraser). Regardless, it seems reasonable to ensure the driver's state variables match programmer expectation. Link: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina

HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN

2024-10-11T09:12:19Z

Unlike EMR tools which encode type information in their tool ID, tools for AES sensors are all "generic pens". It is inappropriate to make use of the wacom_intuos_get_tool_type function when dealing with these kinds of devices. Instead, we should only ever report BTN_TOOL_PEN or BTN_TOOL_RUBBER, as depending on the state of the Eraser and Invert bits. Reported-by: Daniel Jutz Closes: https://lore.kernel.org/linux-input/3cd82004-c5b8-4f2a-9a3b-d88d855c65e4@heusel.eu/ Bisected-by: Christian Heusel Fixes: 9c2913b962da ("HID: wacom: more appropriate tool type categorization") Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1041 Link: https://github.com/linuxwacom/input-wacom/issues/440 Signed-off-by: Jason Gerecke Cc: stable@vger.kernel.org Acked-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

Merge branch 'for-6.12/wacom' into for-linus

2024-09-13T13:21:44Z

Various Wacom fixes (Jason Gerecke): - Support for high-resolution wheel scrolling - Support touchrings with relative motion - Support devices with two touchrings - Support sequence numbers smaller than 16-bit