From: Lee Jones <lee@kernel.org> Date: 2026-09-09 11:13:08
Replace the lookup-dependent 'wacom_wac->shared->touch->product' references
with 'hdev->product' inside wacom_setup_touch_input_capabilities() since
'hdev' is already available (via container_of) and represents the touch
device itself.
Cc: stable@vger.kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
---
v7 -> v8: New patch
v8 -> v9: No change
v9 -> v10: No change
drivers/hid/wacom_wac.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
From: Lee Jones <lee@kernel.org> Date: 2026-09-09 11:13:14
wacom_intuos_pad() accesses wacom->shared->touch_input locklessly
inside the interrupt handler context. If the Touch sibling device
is disconnected, wacom_remove_shared_data() clears 'touch_input'
outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU)
race condition where a preempted reader in interrupt context
dereferences the freed pointer, leading to a Use-After-Free.
Resolve this by introducing RCU protection for the touch_input
pointer:
- Annotate 'touch_input' in wacom_shared struct with __rcu
- Wrap all lockless readers in wacom_wac.c with guard(rcu)() and
rcu_dereference() using a unified wacom_report_touch_mute()
helper
- Update writers in wacom_sys.c using rcu_assign_pointer()
- Call synchronize_rcu() in wacom_remove_shared_data() to ensure
all active RCU readers have finished before the input device is
freed
Also wrap wacom_set_shared_values() and touch/pen assignments in
wacom_add_shared_data() inside the wacom_udev_list_lock to serialize
concurrent probe assignments, and verify that 'shared->touch == hdev'
before setting touch_input to prevent concurrent sibling probe state
desynchronization.
Cc: stable@vger.kernel.org
Fixes: 961794a00eab ("Input: wacom - add reporting of SW_MUTE_DEVICE events")
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 -> v2: Split and use RCU as per Dmitry's review
v2 -> v3: Sashiko fixes
v3 -> v4: Dmitry's review [redundant check and guard()]
v4 -> v5: Jason's review [split, remove "awkward if"]
v5 -> v6: No change
v6 -> v7: No change
v7 -> v8: No functional change - cleaned up a stray whitespace/blank line deletion hunk
v8 -> v9: No change
v9 -> v10: No change
drivers/hid/wacom_sys.c | 23 ++++++++++++++++-------
drivers/hid/wacom_wac.c | 36 ++++++++++++++++++------------------
drivers/hid/wacom_wac.h | 2 +-
3 files changed, 35 insertions(+), 26 deletions(-)
@@ -285,7 +285,7 @@ struct wacom_shared {/* for wireless device to access USB interfaces */unsignedtouch_max;inttype;-structinput_dev*touch_input;+structinput_dev__rcu*touch_input;structhid_device*pen;structhid_device*touch;boolhas_mute_touch_switch;
From: Lee Jones <lee@kernel.org> Date: 2026-09-09 11:13:15
Input subsystem guidelines require that device capabilities are advertised
before the input device is registered. The Wacom driver was violating
this by advertising the SW_MUTE_DEVICE capability post-registration in
wacom_set_shared_values() (and duplicating it in device-specific setup
cases).
Resolve this by moving the SW_MUTE_DEVICE capability setup to
wacom_setup_touch_input_capabilities() for all touch devices that support
it.
For generic touch devices whose capabilities depend on mute switch
usages parsed from a sibling Pen/Pad interface, defer registration
with -EPROBE_DEFER until the sibling has parsed its descriptors and
initialized shared capabilities.
Cc: stable@vger.kernel.org
Fixes: d2ec58aee8b1 ("HID: wacom: generic: support generic touch switch")
Signed-off-by: Lee Jones <lee@kernel.org>
---
v4 -> v5: New patch used to split out SW_MUTE_DEVICE as per Jason's request
v5 -> v6: Unconditionally advertise SW_MUTE_DEVICE on generic touch devices
v6 -> v7: Only advertise SW_MUTE_DEVICE on composite USB generic touch devices
v7 -> v8: Replace heuristic with probe deferral until sibling Pen/Pad is parsed
Split out 'hdev->product' cleanups into a separate standalone patch
v8 -> v9: Fix TOCTOU race by assigning shared sibling pointers in wacom_set_shared_values()
Support Pad interfaces in sibling deferral logic
v9 -> v10: Defer probe if unprobed sibling HID interface exists on composite
USB device
Ensure standalone generic touch devices advertise SW_MUTE_DEVICE
Use acquire memory barrier (smp_load_acquire) when reading shared
sibling state
Cancel pending init_work in fail_hw_stop error path after stopping
hardware
Move has_mute_touch_switch write inside wacom_udev_list_lock
Only assign shared->pen for Pen devices to prevent overwrite by Pad
drivers/hid/wacom_sys.c | 95 ++++++++++++++++++++++++++++++++---------
drivers/hid/wacom_wac.c | 5 +++
2 files changed, 80 insertions(+), 20 deletions(-)
@@ -907,19 +907,14 @@ static int wacom_add_shared_data(struct hid_device *hdev)list_add_tail(&data->list,&wacom_udev_list);}-mutex_unlock(&wacom_udev_list_lock);-wacom_wac->shared=&data->shared;+if(wacom_wac->has_mute_touch_switch)+WRITE_ONCE(wacom_wac->shared->has_mute_touch_switch,true);++mutex_unlock(&wacom_udev_list_lock);+retval=devm_add_action_or_reset(&hdev->dev,wacom_remove_shared_data,wacom);-if(retval)-returnretval;--if(wacom_wac->features.device_type&WACOM_DEVICETYPE_TOUCH)-wacom_wac->shared->touch=hdev;-elseif(wacom_wac->features.device_type&WACOM_DEVICETYPE_PEN)-wacom_wac->shared->pen=hdev;-returnretval;}
@@ -2343,13 +2338,12 @@ static void wacom_release_resources(struct wacom *wacom)staticvoidwacom_set_shared_values(structwacom_wac*wacom_wac){-if(wacom_wac->features.device_type&WACOM_DEVICETYPE_TOUCH){-wacom_wac->shared->type=wacom_wac->features.type;-wacom_wac->shared->touch_input=wacom_wac->touch_input;-}+structwacom*wacom=container_of(wacom_wac,structwacom,wacom_wac);++guard(mutex)(&wacom_udev_list_lock);if(wacom_wac->has_mute_touch_switch){-wacom_wac->shared->has_mute_touch_switch=true;+WRITE_ONCE(wacom_wac->shared->has_mute_touch_switch,true);/* Hardware touch switch may be off. Wait until*weknowtheswitchstatetodecideis_touch_on.*Softkeystateshouldbeinitializedto"on"to
@@ -2359,14 +2353,69 @@ static void wacom_set_shared_values(struct wacom_wac *wacom_wac)wacom_wac->shared->is_touch_on=true;}-if(wacom_wac->shared->has_mute_touch_switch&&-wacom_wac->shared->touch_input){-set_bit(EV_SW,wacom_wac->shared->touch_input->evbit);-input_set_capability(wacom_wac->shared->touch_input,EV_SW,-SW_MUTE_DEVICE);+if(wacom_wac->features.device_type&WACOM_DEVICETYPE_TOUCH){+wacom_wac->shared->type=wacom_wac->features.type;+wacom_wac->shared->touch_input=wacom_wac->touch_input;+wacom_wac->shared->touch=wacom->hdev;+}elseif(wacom_wac->features.device_type&WACOM_DEVICETYPE_PEN){+/* Pairs with smp_load_acquire() in wacom_sibling_pending() */+smp_store_release(&wacom_wac->shared->pen,wacom->hdev);}}+staticboolwacom_sibling_pending(structwacom*wacom)+{+conststructwacom_features*features=&wacom->wacom_wac.features;+structhid_device*hdev=wacom->hdev;+structusb_interface*sibling_intf;+intifnum;++if(features->type!=HID_GENERIC||+!(features->device_type&WACOM_DEVICETYPE_TOUCH))+returnfalse;++if(wacom->wacom_wac.shared){+/* Pairs with smp_store_release() in wacom_set_shared_values() */+if(smp_load_acquire(&wacom->wacom_wac.shared->pen))+returnfalse;+}++if(!hid_is_usb(hdev)||!wacom->usbdev||!wacom->intf||+!wacom->intf->cur_altsetting)+returnfalse;++ifnum=wacom->intf->cur_altsetting->desc.bInterfaceNumber;++/*+*OncompositeWacomdevices,thePeninterfaceisalwaysinterface0.+*IftheTouchinterfaceisinterface0,thereisnosiblingPen+*interfaceonthisdevice(standalonetouchdevice).+*/+if(ifnum==0)+returnfalse;++/* Look for the sibling Pen interface at interface 0 */+sibling_intf=usb_ifnum_to_if(wacom->usbdev,0);+if(!sibling_intf||!sibling_intf->cur_altsetting)+returnfalse;++if(sibling_intf->cur_altsetting->desc.bInterfaceClass!=+USB_INTERFACE_CLASS_HID)+returnfalse;++if(sibling_intf->cur_altsetting->desc.bInterfaceSubClass==1&&+(sibling_intf->cur_altsetting->desc.bInterfaceProtocol==1||+sibling_intf->cur_altsetting->desc.bInterfaceProtocol==2))+returnfalse;++/*+*Interface0isacandidateHIDinterfaceonthiscompositedevice+*whoseprobehasnotcompletedyet(shared->penisNULL).Deferuntil+*interface0finishesprobingandregisterssharedvalues.+*/+returntrue;+}+staticintwacom_parse_and_register(structwacom*wacom,boolwireless){structwacom_wac*wacom_wac=&wacom->wacom_wac;
From: Lee Jones <lee@kernel.org> Date: 2026-09-09 11:13:18
wacom_bamboo_pad_pen_event() accesses wacom->shared->pen locklessly
relative to wacom_remove_shared_data() which nullifies it. This
can lead to a Use-After-Free if the sibling device is removed while
events are being processed.
Resolve this by introducing RCU protection for pen and touch
pointers:
- Annotate 'pen' and 'touch' in wacom_shared struct with __rcu.
- Wrap lockless readers in wacom_bamboo_pad_pen_event() with
rcu_read_lock() and rcu_dereference().
- Update writers in wacom_sys.c using rcu_assign_pointer().
- Use rcu_dereference_protected for comparisons under
wacom_udev_list_lock.
- Also use rcu_access_pointer in wacom_sibling_pending() and
wacom_mode_change_work() to avoid warnings (while lockless access in
the latter remains a pre-existing issue).
Cc: stable@vger.kernel.org
Fixes: 8c97a765467c ("HID: wacom: add full support of the Wacom Bamboo PAD")
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 -> v2: Split and use RCU as per Dmitry's review
v2 -> v3: Sashiko fixes
v3 -> v4: Dmitry's review [guard()]
v4 -> v5: No change
v5 -> v6: No change
v6 -> v7: No change
v7 -> v8: No change
v8 -> v9: No change
v9 -> v10: Use rcu_access_pointer() for __rcu annotated shared->pen in
wacom_sibling_pending()
drivers/hid/wacom_sys.c | 40 ++++++++++++++++++++++++++--------------
drivers/hid/wacom_wac.c | 13 ++++++-------
drivers/hid/wacom_wac.h | 4 ++--
3 files changed, 34 insertions(+), 23 deletions(-)
From: Lee Jones <lee@kernel.org> Date: 2026-09-09 11:13:22
The Wacom driver coordinates state between sibling interfaces of
the same physical device using a shared structure 'wacom_shared'
inside 'wacom_hdev_data'. The driver kept a volatile representative
pointer 'data->dev' pointing to a sibling 'hid_device' for physical
path comparisons during sibling matching.
This pointer management is fragile. When the representative device
is disconnected, wacom_remove_shared_data() failed to clear/update
'data->dev', leading to a Use-After-Free vulnerability when
subsequent sibling probes dereference the dangling 'data->dev'
pointer.
Resolve this issue by redesigning the sibling data lifecycle:
- Eliminate the volatile 'data->dev' representative pointer
completely
- Redesign 'wacom_hdev_data' to store stable static copies of the
required attributes upon first allocation: 'phys' path string,
'vendor', 'product' IDs and the sibling's 'device_type'
- Use these static attributes for stable sibling matching in
wacom_are_sibling() and wacom_get_hdev_data()
This ensures sibling matching remains safe and stable even if
individual siblings are dynamically added or removed.
To secure the lifecycle against concurrent probe/disconnect races:
- Switch kref_put() to kref_put_mutex() in
wacom_remove_shared_data() to serialize refcount drops with list
traversal and lookup
- Modify wacom_release_shared_data() to assume the list lock is
already held
Also, do not accumulate the 'device_type' capability flag during
subsequent sibling probes. Keeping only the first probed sibling's
device_type exactly preserves the original sibling matching behavior
without introducing side effects.
Cc: stable@vger.kernel.org
Fixes: 4492efffffeb ("Input: wacom - share pen info with touch of the same ID")
Signed-off-by: Lee Jones <lee@kernel.org>
---
v1 -> v2: Split and use RCU as per Dmitry's review
v2 -> v3: Sashiko fixes
v3 -> v4: No change
v4 -> v5: No change
v5 -> v6: No change
v6 -> v7: No change
v7 -> v8: No change
v8 -> v9: No change
v9 -> v10: No change
drivers/hid/wacom_sys.c | 70 +++++++++++++++++++++++++++--------------
1 file changed, 46 insertions(+), 24 deletions(-)
@@ -757,27 +757,47 @@ static void wacom_retrieve_hid_descriptor(struct hid_device *hdev,structwacom_hdev_data{structlist_headlist;structkrefkref;-structhid_device*dev;+charphys[64];+__u32vendor;+__u32product;+__u32device_type;structwacom_sharedshared;};+staticboolwacom_compare_device_paths(structhid_device*hdev_a,+constchar*phys_b,charseparator)+{+constchar*p1=strrchr(hdev_a->phys,separator);+constchar*p2=strrchr(phys_b,separator);+intn1,n2;++if(!p1||!p2)+returnfalse;++n1=p1-hdev_a->phys;+n2=p2-phys_b;++if(n1!=n2||n1<=0||n2<=0)+returnfalse;++return!strncmp(hdev_a->phys,phys_b,n1);+}+staticLIST_HEAD(wacom_udev_list);staticDEFINE_MUTEX(wacom_udev_list_lock);staticboolwacom_are_sibling(structhid_device*hdev,-structhid_device*sibling)+structwacom_hdev_data*data){structwacom*wacom=hid_get_drvdata(hdev);structwacom_features*features=&wacom->wacom_wac.features;-structwacom*sibling_wacom=hid_get_drvdata(sibling);-structwacom_features*sibling_features=&sibling_wacom->wacom_wac.features;__u32oVid=features->oVid?features->oVid:hdev->vendor;__u32oPid=features->oPid?features->oPid:hdev->product;/* The defined oVid/oPid must match that of the sibling */-if(features->oVid!=HID_ANY_ID&&sibling->vendor!=oVid)+if(features->oVid!=HID_ANY_ID&&data->vendor!=oVid)returnfalse;-if(features->oPid!=HID_ANY_ID&&sibling->product!=oPid)+if(features->oPid!=HID_ANY_ID&&data->product!=oPid)returnfalse;/*
@@ -810,17 +830,17 @@ static bool wacom_are_sibling(struct hid_device *hdev,*devices.*/if(!(features->device_type&WACOM_DEVICETYPE_DIRECT)&&-(sibling_features->device_type&WACOM_DEVICETYPE_DIRECT))+(data->device_type&WACOM_DEVICETYPE_DIRECT))returnfalse;/* Pen devices may only be siblings of touch devices */if((features->device_type&WACOM_DEVICETYPE_PEN)&&-!(sibling_features->device_type&WACOM_DEVICETYPE_TOUCH))+!(data->device_type&WACOM_DEVICETYPE_TOUCH))returnfalse;/* Touch devices may only be siblings of pen devices */if((features->device_type&WACOM_DEVICETYPE_TOUCH)&&-!(sibling_features->device_type&WACOM_DEVICETYPE_PEN))+!(data->device_type&WACOM_DEVICETYPE_PEN))returnfalse;/*
@@ -836,7 +856,7 @@ static struct wacom_hdev_data *wacom_get_hdev_data(struct hid_device *hdev)/* Try to find an already-probed interface from the same device */list_for_each_entry(data,&wacom_udev_list,list){-if(hid_compare_device_paths(hdev,data->dev,'/')){+if(wacom_compare_device_paths(hdev,data->phys,'/')){kref_get(&data->kref);returndata;}
@@ -844,7 +864,7 @@ static struct wacom_hdev_data *wacom_get_hdev_data(struct hid_device *hdev)/* Fallback to finding devices that appear to be "siblings" */list_for_each_entry(data,&wacom_udev_list,list){-if(wacom_are_sibling(hdev,data->dev)){+if(wacom_are_sibling(hdev,data)){kref_get(&data->kref);returndata;}
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Lockless access to `shared->pen` and `shared->touch` in `wacom_mode_change_work()` leads to a Use-After-Free.
--
commit 128e0f492fb46bf1508b21d7d9f05ef9e57ed2be
Author: Lee Jones [off-list ref]
HID: wacom: Fix Use-After-Free in wacom_bamboo_pad
This commit introduces RCU protection for the pen and touch pointers in the
wacom_shared structure to resolve a Use-After-Free during sibling device
removal. It updates lockless readers with rcu_read_lock() and uses
rcu_assign_pointer() in writers.
[Severity: Critical]
This is a pre-existing issue, but could this lockless access to shared->pen
and shared->touch lead to a Use-After-Free here?
The commit message explicitly notes that lockless access in this work item
remains a pre-existing issue. The removal path nullifies the shared pointer
and calls synchronize_rcu(). However, wacom_mode_change_work() accesses the
pointers using rcu_access_pointer() without establishing an RCU read-side
critical section using rcu_read_lock().
Because there is no active RCU reader, synchronize_rcu() does not wait for
this work item to finish. If a device report schedules this work, and the
sibling device is concurrently unplugged, won't the sibling device's
resources be freed while wacom_mode_change_work() is actively dereferencing
the stale pointer via hid_get_drvdata(pen) and hid_hw_stop()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/fa3cb42f7b58c1b3022d8208969a81882783a5ec.1788868602.git.lee@kernel.org?part=4
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing cancellation of asynchronous works and timers in the probe error path leads to use-after-free.
--
commit ca8b53c76679ad840d06b68ac883d22ba58fe317
Author: Lee Jones [off-list ref]
Subject: HID: wacom: Use hdev->product in wacom_setup_touch_input_capabilities
This commit replaces lookup-dependent touch product references with
hdev->product inside wacom_setup_touch_input_capabilities(). This
simplifies the code since hdev is already available via container_of
and represents the touch device itself.
[ ... ]
While reviewing the wacom driver lifecycle, I noticed a potential issue in
a related file during the probe error path:
drivers/hid/wacom_sys.c:wacom_parse_and_register() {
...
if (features->device_type & WACOM_DEVICETYPE_WL_MONITOR) {
error = hid_hw_open(hdev);
if (error) {
hid_err(hdev, "hw open failed\n");
goto fail_hw_stop;
}
}
...
fail_hw_stop:
hid_hw_stop(hdev);
fail:
wacom_release_resources(wacom);
return error;
}
[Severity: Critical]
This is a pre-existing issue, but does this error path leave asynchronous
works and timers running after freeing the wacom structure?
The driver allocates the wacom structure using devm_kzalloc(). If an
initialization step fails after hid_hw_start() is called, such as
hid_hw_open() failing, the code jumps to the fail_hw_stop label.
While hid_hw_stop() is called, it appears to omit cancelling other
asynchronous resources like wireless_work, battery_work, remote_work,
mode_change_work, aes_battery_work, and idleprox_timer.
Since hid_hw_start() enables hardware interrupts, an incoming interrupt can
trigger wacom_raw_event() -> wacom_wac_irq() -> wacom_schedule_work(),
which queues these works.
If the probe function returns an error, devres will automatically free the
wacom structure. Could an untrusted device triggering rapid reports cause
these pending works to execute later and dereference the freed memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/fa3cb42f7b58c1b3022d8208969a81882783a5ec.1788868602.git.lee@kernel.org?part=1
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Lockless access to `shared->pen` and `shared->touch` leaves sibling `hid_device` pointers vulnerable to Use-After-Free during concurrent hot-unplug.
- [High] Sysfs callbacks access `wacom->led.groups` without NULL checks, racing with `wacom_remove()` cleanup.
--
commit f9df2fb1ac73b67929633c2e25c6e475a7abd240
Author: Lee Jones [off-list ref]
HID: wacom: Fix Use-After-Free in wacom_intuos_pad
wacom_intuos_pad() accesses wacom->shared->touch_input locklessly
inside the interrupt handler context. If the Touch sibling device
is disconnected, wacom_remove_shared_data() clears 'touch_input'
outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU)
race condition where a preempted reader in interrupt context
dereferences the freed pointer, leading to a Use-After-Free.
[Severity: High]
This is a pre-existing issue, but since this patch introduces RCU protection
for touch_input, is it possible that lockless access to shared->pen and
shared->touch in wacom_mode_change_work() is still vulnerable to a
Use-After-Free during concurrent hot-unplug?
When a sibling interface is unbound, devres automatically frees its driver
data. If a WACOM_HID_WD_MODE_CHANGE event concurrently schedules
wacom_mode_change_work(), it accesses these pointers locklessly:
drivers/hid/wacom_sys.c:wacom_mode_change_work() {
...
if (shared->pen) {
wacom1 = hid_get_drvdata(shared->pen);
wacom_release_resources(wacom1);
hid_hw_stop(wacom1->hdev);
...
if (shared->touch) {
wacom2 = hid_get_drvdata(shared->touch);
wacom_release_resources(wacom2);
hid_hw_stop(wacom2->hdev);
...
}
While Patch 5/5 in this series attempts to fix this by replacing the raw
accesses with rcu_access_pointer(), it appears to omit wrapping the worker
in an RCU read-side critical section and doesn't use rcu_dereference().
Because of this, would the synchronize_rcu() call in the unbind path fail to
wait for this worker, leaving the Use-After-Free vulnerability unresolved
at the end of the series?
[ ... ]
[Severity: High]
This is a pre-existing issue, but could wacom_show_remote_mode() race with
wacom_remove() and cause a NULL pointer dereference?
During unbind, wacom_remove() explicitly nullifies the groups pointer before
devres removes the sysfs attributes:
drivers/hid/wacom_sys.c:wacom_remove() {
...
/* make sure we don't trigger the LEDs */
wacom_led_groups_release(wacom);
if (wacom->wacom_wac.features.type != REMOTE)
wacom_release_resources(wacom);
}
If an unprivileged local user continuously reads the world-readable sysfs
files during a hot-unplug, the sysfs callback dereferences wacom->led.groups
without a NULL check:
drivers/hid/wacom_sys.c:wacom_show_remote_mode() {
...
mode = wacom->led.groups[index].select;
return sprintf(buf, "%d\n", mode < 3 ? mode : -1);
}
Could this crash the kernel if the sysfs read callback executes after
wacom_led_groups_release() clears the pointer, but before devres cleanup
finishes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/fa3cb42f7b58c1b3022d8208969a81882783a5ec.1788868602.git.lee@kernel.org?part=3
Tested the whole set of v10. Status stays the same:
Acked-by: Ping Cheng <ping.cheng@wacom.com>
Tested-by: Ping Cheng <ping.cheng@wacom.com>
Cheers,
Ping
On Wed, Sep 9, 2026 at 4:27 AM Lee Jones [off-list ref] wrote:
quoted hunk
Replace the lookup-dependent 'wacom_wac->shared->touch->product' references
with 'hdev->product' inside wacom_setup_touch_input_capabilities() since
'hdev' is already available (via container_of) and represents the touch
device itself.
Cc: stable@vger.kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
---
v7 -> v8: New patch
v8 -> v9: No change
v9 -> v10: No change
drivers/hid/wacom_wac.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
Replace the lookup-dependent 'wacom_wac->shared->touch->product' references
with 'hdev->product' inside wacom_setup_touch_input_capabilities() since
'hdev' is already available (via container_of) and represents the touch
device itself.
Cc: stable@vger.kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Replace the lookup-dependent 'wacom_wac->shared->touch->product' references
with 'hdev->product' inside wacom_setup_touch_input_capabilities() since
'hdev' is already available (via container_of) and represents the touch
device itself.
Cc: stable@vger.kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>