* Re: [PATCH 2/4] virtio_input: validate device-reported multitouch slot count
From: Dmitry Torokhov @ 2026-07-16 17:33 UTC (permalink / raw)
To: Hari Mishal
Cc: Michael S. Tsirkin, Amit Shah, Arnd Bergmann, Greg Kroah-Hartman,
Gerd Hoffmann, Jason Wang, David Hildenbrand, Henrik Rydberg,
Xuan Zhuo, Eugenio Pérez, virtualization, linux-kernel,
linux-input
In-Reply-To: <alkTnRb9qhgcMGGi@google.com>
[ Just realized that CC was dropped in the email I was replying to, so
restoring and resending... ]
On Thu, Jul 16, 2026 at 10:28:36AM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 16, 2026 at 12:34:57PM +0200, Hari Mishal wrote:
> > > What is the failure mode if we keep the ABS_MT_SLOT capability? Does the
> > > kernel crash? And if this can cause crash then we should fix
> > > input_mt_init_slots() to reject requests for 0 slots with -EINVAL.
> > >
> >
> > No, it doesn't crash. I think every place in the input core that touches
> > dev->mt guards against it being NULL: input_handle_abs_event() and
> > the mt_slots check in input.c, and evdev's EVIOCGMTSLOTS ioctl
> > handler all explicitly check for NULL and degrade cleanly instead of
> > dereferencing. From my understanding, the worst case is what the
> > original commit message already covers: the device advertises
> > multitouch support it can't back.
>
> So what? I still do not see the problem. Let's say I have a device that
> properly supports multitouch and has slots, but then never sends any
> events because firmware is buggy. How would that affect anything?
>
> If there is no crash that I would leave the driver alone.
>
> And we need to remember that we are dealing with a hypervisor here that
> normally had higher level of trust than the VM. If it messes up we do
> not have to clean up after it. This scenario is different from user
> attaching a malicious USB device to their system and getting owned.
>
> Thanks.
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v9 0/9] Add support for MT6392 PMIC
From: Lee Jones @ 2026-07-16 15:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Louis-Alexis Eyraud, Val Packett, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260621081634.467858-1-l.scorcia@gmail.com>
On Sun, 21 Jun 2026, Luca Leonardo Scorcia wrote:
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
>
> This series is mostly based around patches submitted a couple
> years ago by Fabien Parent and not merged and from Val Packett's
> submission from Jan 2025 that included extra cleanups, fixes, and a
> new dtsi file similar to ones that exist for other PMICs. Some
> comments weren't addressed and the series was ultimately not merged.
The MFD pieces look fine.
Let me know when you have the rest of the Acks and I'll merge the set.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: intel-ish-hid: ipc: Remove redundant dev_err()
From: srinivas pandruvada @ 2026-07-16 14:40 UTC (permalink / raw)
To: Pan Chuang, Jiri Kosina, Benjamin Tissoires, Zhang Lixu,
Andy Shevchenko, Vineeth Pillai,
open list:INTEL INTEGRATED SENSOR HUB DRIVER, open list
In-Reply-To: <20260716075203.593012-4-panchuang@vivo.com>
On Thu, 2026-07-16 at 15:51 +0800, Pan Chuang wrote:
> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> devm_request_*_irq()"), devm_request_irq() automatically logs
> detailed error messages on failure. Remove the now-redundant
> driver-specific dev_err() calls.
>
> Signed-off-by: Pan Chuang <panchuang@vivo.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 8d36ae96a3ee..e7196e429c8b 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -232,10 +232,8 @@ static int ish_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>
> ret = devm_request_irq(dev, pdev->irq, ish_irq_handler,
> irq_flag, KBUILD_MODNAME, ishtp);
> - if (ret) {
> - dev_err(dev, "ISH: request IRQ %d failed\n", pdev-
> >irq);
> + if (ret)
> return ret;
> - }
>
> dev_set_drvdata(ishtp->devc, ishtp);
>
^ permalink raw reply
* Re: [PATCH v4] HID: i2c-hid: Fix "(null)" output when reading report descriptor fails
From: Mario Limonciello @ 2026-07-16 13:50 UTC (permalink / raw)
To: Ai Chao, jikos, bentiss, dianders, treapking, kenkinming2002,
raoxu
Cc: linux-input, linux-kernel
In-Reply-To: <20260716112932.4038146-1-aichao@kylinos.cn>
On 7/16/26 06:29, Ai Chao wrote:
> When i2c-hid fails to read the HID report descriptor during device
> initialization, the error message prints as:
>
> hid (null): reading report descriptor failed
>
> The HID device name is set in hid_add_device() after calling
> hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls
> hid_err(), the device name has not been set yet, resulting in "(null)"
> output.
>
> Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because
> the I2C client device is fully initialized with a proper name, providing
> meaningful error messages for debugging.
>
> Before: hid (null): reading report descriptor failed
> After: i2c_hid i2c-TPD0001:00: reading report descriptor failed
>
> Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation")
>
> Signed-off-by: Ai Chao <aichao@kylinos.cn>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> change for v4
> - Add Fixes tag.
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 3adb16366e93..0e725a0f0abe 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -792,7 +792,7 @@ static int i2c_hid_parse(struct hid_device *hid)
> ihid->hdesc.wReportDescRegister,
> rdesc, rsize);
> if (ret) {
> - hid_err(hid, "reading report descriptor failed\n");
> + dev_err(&client->dev, "reading report descriptor failed\n");
> goto out;
> }
> }
^ permalink raw reply
* [PATCH v4] HID: i2c-hid: Fix "(null)" output when reading report descriptor fails
From: Ai Chao @ 2026-07-16 11:29 UTC (permalink / raw)
To: jikos, bentiss, dianders, treapking, kenkinming2002, raoxu,
superm1
Cc: linux-input, linux-kernel, Ai Chao
When i2c-hid fails to read the HID report descriptor during device
initialization, the error message prints as:
hid (null): reading report descriptor failed
The HID device name is set in hid_add_device() after calling
hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls
hid_err(), the device name has not been set yet, resulting in "(null)"
output.
Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because
the I2C client device is fully initialized with a proper name, providing
meaningful error messages for debugging.
Before: hid (null): reading report descriptor failed
After: i2c_hid i2c-TPD0001:00: reading report descriptor failed
Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation")
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
change for v4
- Add Fixes tag.
---
drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3adb16366e93..0e725a0f0abe 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -792,7 +792,7 @@ static int i2c_hid_parse(struct hid_device *hid)
ihid->hdesc.wReportDescRegister,
rdesc, rsize);
if (ret) {
- hid_err(hid, "reading report descriptor failed\n");
+ dev_err(&client->dev, "reading report descriptor failed\n");
goto out;
}
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Input: wacom_w8001 - replace strlcat() with a strscpy() helper
From: David Laight @ 2026-07-16 9:32 UTC (permalink / raw)
To: Ian Bridges; +Cc: Dmitry Torokhov, linux-input, linux-kernel, linux-hardening
In-Reply-To: <albg4Rv7QxvLJD05@dev>
On Tue, 14 Jul 2026 20:22:41 -0500
Ian Bridges <icb@fastmail.org> wrote:
> In preparation for removing the strlcat() API[1], replace its five
> uses with a small append helper built on strnlen() and strscpy().
>
> The five calls append device name fragments to a basename buffer
> that grows in place across the setup functions. The helper takes
> the same arguments as strlcat() and writes the same bytes, including
> when a fragment is truncated.
You can do much better than that...
Change w8001_setup_touch/pen() to return the 'const char *' name,
then put everything together in the final snprintf().
David
^ permalink raw reply
* Re: [PATCH v6 2/4] HID: wacom: Fix Use-After-Free in wacom_intuos_pad
From: sashiko-bot @ 2026-07-16 9:26 UTC (permalink / raw)
To: Lee Jones; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260716090726.2711293-2-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Lockless access to sibling device pointers in wacom_mode_change_work() leads to concurrent double-free and Use-After-Free.
- [High] wacom_remove_shared_data() calls kref_put() outside of the list lock, creating a race condition that leads to refcount corruption and Use-After-Free.
- [High] The patch protects touch_input with RCU but fails to protect shared->pen and shared->touch, leaving a Use-After-Free vulnerability in IRQ paths.
--
--- Patch [2]: [PATCH v6 2/4] HID: wacom: Fix Use-After-Free in wacom_intuos_pad ---
commit db13f6a5a689d086da00c273947930e39aedbb61
Author: Lee Jones <lee@kernel.org>
HID: wacom: Fix Use-After-Free in wacom_intuos_pad
This patch attempts to fix a TOCTOU Use-After-Free race condition by
introducing RCU protection for the touch_input pointer in the wacom_shared
struct, wrapping readers in RCU guards, updating writers, and calling
synchronize_rcu().
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 6c2a3ddfe366a..c6b37931d02d1 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -875,10 +875,16 @@ static void wacom_remove_shared_data(void *res)
> data = container_of(wacom_wac->shared, struct wacom_hdev_data,
> shared);
>
> - if (wacom_wac->shared->touch == wacom->hdev)
> - wacom_wac->shared->touch = NULL;
> - else if (wacom_wac->shared->pen == wacom->hdev)
> - wacom_wac->shared->pen = NULL;
> + scoped_guard(mutex, &wacom_udev_list_lock) {
> + if (wacom_wac->shared->touch == wacom->hdev) {
> + wacom_wac->shared->touch = NULL;
> + rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
> + } else if (wacom_wac->shared->pen == wacom->hdev) {
> + wacom_wac->shared->pen = NULL;
> + }
> + }
[Severity: High]
This is a pre-existing issue, but does shared->pen (and shared->touch) need
the same RCU protection that is being added here for touch_input?
For instance, in wacom_bamboo_pad_pen_event(), shared->pen is accessed
locklessly in an interrupt handler:
drivers/hid/wacom_wac.c:wacom_bamboo_pad_pen_event() {
...
hid_input_report(wacom->shared->pen, HID_INPUT_REPORT, data,
WACOM_PKGLEN_PENABLED, 1);
...
}
If the Pen sibling device is disconnected concurrently,
wacom_remove_shared_data() clears shared->pen here. Could a preempted or
concurrent IRQ read the non-NULL shared->pen pointer before it is cleared,
and pass the dangling pointer to hid_input_report() once the Pen device is
unbound and freed?
Additionally, in wacom_mode_change_work(), there is lockless access to
these sibling device pointers:
drivers/hid/wacom_sys.c:wacom_mode_change_work() {
...
wacom1 = hid_get_drvdata(shared->pen);
wacom_release_resources(wacom1);
hid_hw_stop(wacom1->hdev);
...
}
Could the asynchronous worker on a Touch device read shared->pen concurrently
with the Pen device being unbound, leading to a concurrent double-free or
Use-After-Free of the device memory?
> +
> + synchronize_rcu();
>
> kref_put(&data->kref, wacom_release_shared_data);
[Severity: High]
This isn't a bug introduced by this patch, but since kref_put() is called
here outside of the wacom_udev_list_lock, can this create a race condition
that leads to refcount corruption?
If the refcount drops to 0, it calls the release function which waits for
the lock to remove the object from wacom_udev_list. Concurrently, couldn't a
probe on another device acquire the lock and iterate the list:
drivers/hid/wacom_sys.c:wacom_get_hdev_data() {
...
kref_get(&data->kref);
return data;
...
}
Could this result in incrementing a 0-refcount object, causing a
Use-After-Free when the original thread proceeds to unlink and free the
structure?
> wacom_wac->shared = NULL;
> }
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716090726.2711293-1-lee@kernel.org?part=2
^ permalink raw reply
* Re: [PATCH v6 3/4] HID: wacom: Fix Use-After-Free in wacom_bamboo_pad
From: sashiko-bot @ 2026-07-16 9:20 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260716090726.2711293-3-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Unbinding the primary interface leaves a dangling or unbound `data->dev` pointer in `wacom_udev_list`, causing a crash on subsequent device probes.
- [High] Lockless and un-synchronized dereference of `shared->pen` and `shared->touch` in `wacom_mode_change_work()` leads to a Use-After-Free.
--
--- Patch [3]: [PATCH v6 3/4] HID: wacom: Fix Use-After-Free in wacom_bamboo_pad ---
commit bc217aafc6e3e6dc78c0e754ee61de0854395e8e
Author: Lee Jones <lee@kernel.org>
Date: Thu Jul 16 09:07:14 2026 +0000
HID: wacom: Fix Use-After-Free in wacom_bamboo_pad
This patch resolves a use-after-free vulnerability when a sibling device
is removed while events are being processed in wacom_bamboo_pad_pen_event().
It introduces RCU protection for pen and touch pointers in the wacom_shared
struct to synchronize readers and writers safely.
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index c6b37931d02d1..5578de80f4c80 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -876,11 +876,18 @@ static void wacom_remove_shared_data(void *res)
[Severity: High]
This isn't a bug introduced by this patch, but can unbinding the primary
interface leave a dangling pointer in wacom_udev_list, causing a crash on
subsequent device probes?
If a device with multiple interfaces is probed, and the first interface
allocates wacom_hdev_data, the second interface will increment its refcount.
If the first interface is unbound, its hdev is destroyed by the HID core, but
the shared data structure is kept alive by the second interface's refcount.
Does this leave a dangling pointer?
When a new device is probed, could wacom_get_hdev_data() iterate over
wacom_udev_list and call wacom_are_sibling(), resulting in accesses to the
freed hdev?
drivers/hid/wacom_sys.c:wacom_are_sibling() {
...
if (features->oVid != HID_ANY_ID && sibling->vendor != oVid)
...
if (!(sibling_features->device_type & WACOM_DEVICETYPE_DIRECT))
...
}
Could this lead to accessing a freed hdev or dereferencing an invalid offset
if hid_get_drvdata(sibling) returns NULL?
> shared);
>
> scoped_guard(mutex, &wacom_udev_list_lock) {
> - if (wacom_wac->shared->touch == wacom->hdev) {
> - wacom_wac->shared->touch = NULL;
> + struct hid_device *touch =
> + rcu_dereference_protected(wacom_wac->shared->touch,
> + lockdep_is_held(&wacom_udev_list_lock));
[ ... ]
> @@ -2793,16 +2804,19 @@ static void wacom_mode_change_work(struct work_struct *work)
> bool is_direct = wacom->wacom_wac.is_direct_mode;
> int error = 0;
>
> - if (shared->pen) {
> - wacom1 = hid_get_drvdata(shared->pen);
> + struct hid_device *pen = rcu_access_pointer(shared->pen);
> + struct hid_device *touch = rcu_access_pointer(shared->touch);
> +
> + if (pen) {
> + wacom1 = hid_get_drvdata(pen);
[Severity: High]
This isn't a bug introduced by this patch, but does the lockless and
unsynchronized dereference of shared->pen and shared->touch in
wacom_mode_change_work() lead to a use-after-free?
The patch introduces rcu_access_pointer() here to avoid sparse warnings, but
reads the pointer using rcu_access_pointer() which is intended only for
testing for NULL, not for subsequent dereferencing outside an RCU critical
section.
Since wacom_mode_change_work() does not hold rcu_read_lock() nor acquire a
stable reference to the underlying hid_device, if the pen or touch device is
concurrently unbound, wacom_remove_shared_data() nullifies the pointers and
calls synchronize_rcu().
Because wacom_mode_change_work() does not hold the RCU lock,
synchronize_rcu() doesn't wait for it to finish.
Once the device is freed, won't wacom_mode_change_work() proceed to
dereference the dangling pointer in hid_get_drvdata(pen) and hid_hw_stop()?
> wacom_release_resources(wacom1);
> hid_hw_stop(wacom1->hdev);
> wacom1->wacom_wac.has_mode_change = true;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716090726.2711293-1-lee@kernel.org?part=3
^ permalink raw reply
* Re: [PATCH v6 1/4] HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration
From: sashiko-bot @ 2026-07-16 9:17 UTC (permalink / raw)
To: Lee Jones; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260716090726.2711293-1-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Direct bit manipulation is used to set the SW_MUTE_DEVICE capability instead of the preferred input_set_capability() helper.
--
--- Patch [1]: [PATCH v6 1/4] HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration ---
commit 5e17768d036dad9565ea2c66ff5662065517024d
Author: Lee Jones <lee@kernel.org>
HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration
This commit moves the SW_MUTE_DEVICE capability advertisement for touch
devices to wacom_setup_touch_input_capabilities() to comply with input
subsystem guidelines. It also replaces lookup-dependent product
references with hdev->product.
[ ... ]
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625d..6fd1a5bcc28a4 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3961,9 +3963,12 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
> else
> __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>
> - if (features->type == HID_GENERIC)
> + if (features->type == HID_GENERIC) {
> + input_dev->evbit[0] |= BIT_MASK(EV_SW);
> + __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
[Severity: Low]
This isn't a bug, but since this is setting a single capability, would it be
better to use the input_set_capability() helper here instead of direct bit
manipulation?
> /* setup has already been done */
> return 0;
> + }
>
> input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> __set_bit(BTN_TOUCH, input_dev->keybit);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716090726.2711293-1-lee@kernel.org?part=1
^ permalink raw reply
* [PATCH v6 4/4] HID: wacom: Redesign shared sibling data lifecycle
From: Lee Jones @ 2026-07-16 9:07 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Aaron Skomra, Peter Hutterer, Dmitry Torokhov, linux-input,
linux-kernel
In-Reply-To: <20260716090726.2711293-1-lee@kernel.org>
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.
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
drivers/hid/wacom_sys.c | 70 +++++++++++++++++++++++++++--------------
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 5578de80f4c8..8dabbeb8b84f 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -757,27 +757,47 @@ static void wacom_retrieve_hid_descriptor(struct hid_device *hdev,
struct wacom_hdev_data {
struct list_head list;
struct kref kref;
- struct hid_device *dev;
+ char phys[64];
+ __u32 vendor;
+ __u32 product;
+ __u32 device_type;
struct wacom_shared shared;
};
+static bool wacom_compare_device_paths(struct hid_device *hdev_a,
+ const char *phys_b, char separator)
+{
+ const char *p1 = strrchr(hdev_a->phys, separator);
+ const char *p2 = strrchr(phys_b, separator);
+ int n1, n2;
+
+ if (!p1 || !p2)
+ return false;
+
+ n1 = p1 - hdev_a->phys;
+ n2 = p2 - phys_b;
+
+ if (n1 != n2 || n1 <= 0 || n2 <= 0)
+ return false;
+
+ return !strncmp(hdev_a->phys, phys_b, n1);
+}
+
static LIST_HEAD(wacom_udev_list);
static DEFINE_MUTEX(wacom_udev_list_lock);
static bool wacom_are_sibling(struct hid_device *hdev,
- struct hid_device *sibling)
+ struct wacom_hdev_data *data)
{
struct wacom *wacom = hid_get_drvdata(hdev);
struct wacom_features *features = &wacom->wacom_wac.features;
- struct wacom *sibling_wacom = hid_get_drvdata(sibling);
- struct wacom_features *sibling_features = &sibling_wacom->wacom_wac.features;
__u32 oVid = features->oVid ? features->oVid : hdev->vendor;
__u32 oPid = 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)
return false;
- if (features->oPid != HID_ANY_ID && sibling->product != oPid)
+ if (features->oPid != HID_ANY_ID && data->product != oPid)
return false;
/*
@@ -785,11 +805,11 @@ static bool wacom_are_sibling(struct hid_device *hdev,
* device path, while those with different VID/PID must share
* the same physical parent device path.
*/
- if (hdev->vendor == sibling->vendor && hdev->product == sibling->product) {
- if (!hid_compare_device_paths(hdev, sibling, '/'))
+ if (hdev->vendor == data->vendor && hdev->product == data->product) {
+ if (!wacom_compare_device_paths(hdev, data->phys, '/'))
return false;
} else {
- if (!hid_compare_device_paths(hdev, sibling, '.'))
+ if (!wacom_compare_device_paths(hdev, data->phys, '.'))
return false;
}
@@ -802,7 +822,7 @@ 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))
return false;
/*
@@ -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))
return false;
/* 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))
return false;
/* 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))
return false;
/*
@@ -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);
return data;
}
@@ -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);
return data;
}
@@ -858,18 +878,15 @@ static void wacom_release_shared_data(struct kref *kref)
struct wacom_hdev_data *data =
container_of(kref, struct wacom_hdev_data, kref);
- mutex_lock(&wacom_udev_list_lock);
list_del(&data->list);
- mutex_unlock(&wacom_udev_list_lock);
-
kfree(data);
}
static void wacom_remove_shared_data(void *res)
{
- struct wacom *wacom = res;
+ struct wacom *res_wacom = res;
struct wacom_hdev_data *data;
- struct wacom_wac *wacom_wac = &wacom->wacom_wac;
+ struct wacom_wac *wacom_wac = &res_wacom->wacom_wac;
if (wacom_wac->shared) {
data = container_of(wacom_wac->shared, struct wacom_hdev_data,
@@ -883,17 +900,19 @@ static void wacom_remove_shared_data(void *res)
rcu_dereference_protected(wacom_wac->shared->pen,
lockdep_is_held(&wacom_udev_list_lock));
- if (touch == wacom->hdev) {
+ if (touch == res_wacom->hdev) {
rcu_assign_pointer(wacom_wac->shared->touch, NULL);
rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
- } else if (pen == wacom->hdev) {
+ } else if (pen == res_wacom->hdev) {
rcu_assign_pointer(wacom_wac->shared->pen, NULL);
}
}
synchronize_rcu();
- kref_put(&data->kref, wacom_release_shared_data);
+ if (kref_put_mutex(&data->kref, wacom_release_shared_data, &wacom_udev_list_lock))
+ mutex_unlock(&wacom_udev_list_lock);
+
wacom_wac->shared = NULL;
}
}
@@ -916,7 +935,10 @@ static int wacom_add_shared_data(struct hid_device *hdev)
}
kref_init(&data->kref);
- data->dev = hdev;
+ strscpy(data->phys, hdev->phys, sizeof(data->phys));
+ data->vendor = hdev->vendor;
+ data->product = hdev->product;
+ data->device_type = wacom_wac->features.device_type;
list_add_tail(&data->list, &wacom_udev_list);
}
--
2.55.0.141.g00534a21ce-goog
^ permalink raw reply related
* [PATCH v6 3/4] HID: wacom: Fix Use-After-Free in wacom_bamboo_pad
From: Lee Jones @ 2026-07-16 9:07 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Aaron Skomra, Dmitry Torokhov, Peter Hutterer, linux-input,
linux-kernel
In-Reply-To: <20260716090726.2711293-1-lee@kernel.org>
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_mode_change_work() to avoid
warnings (while lockless access there remains a pre-existing issue).
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
drivers/hid/wacom_sys.c | 36 +++++++++++++++++++++++++-----------
drivers/hid/wacom_wac.c | 13 ++++++-------
drivers/hid/wacom_wac.h | 4 ++--
3 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index c6b37931d02d..5578de80f4c8 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -876,11 +876,18 @@ static void wacom_remove_shared_data(void *res)
shared);
scoped_guard(mutex, &wacom_udev_list_lock) {
- if (wacom_wac->shared->touch == wacom->hdev) {
- wacom_wac->shared->touch = NULL;
+ struct hid_device *touch =
+ rcu_dereference_protected(wacom_wac->shared->touch,
+ lockdep_is_held(&wacom_udev_list_lock));
+ struct hid_device *pen =
+ rcu_dereference_protected(wacom_wac->shared->pen,
+ lockdep_is_held(&wacom_udev_list_lock));
+
+ if (touch == wacom->hdev) {
+ rcu_assign_pointer(wacom_wac->shared->touch, NULL);
rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
- } else if (wacom_wac->shared->pen == wacom->hdev) {
- wacom_wac->shared->pen = NULL;
+ } else if (pen == wacom->hdev) {
+ rcu_assign_pointer(wacom_wac->shared->pen, NULL);
}
}
@@ -914,9 +921,9 @@ static int wacom_add_shared_data(struct hid_device *hdev)
}
if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
- data->shared.touch = hdev;
+ rcu_assign_pointer(data->shared.touch, hdev);
else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
- data->shared.pen = hdev;
+ rcu_assign_pointer(data->shared.pen, hdev);
mutex_unlock(&wacom_udev_list_lock);
@@ -2354,7 +2361,11 @@ static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
guard(mutex)(&wacom_udev_list_lock);
if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH) {
- if (wacom_wac->shared->touch == wacom->hdev) {
+ struct hid_device *touch =
+ rcu_dereference_protected(wacom_wac->shared->touch,
+ lockdep_is_held(&wacom_udev_list_lock));
+
+ if (touch == wacom->hdev) {
wacom_wac->shared->type = wacom_wac->features.type;
rcu_assign_pointer(wacom_wac->shared->touch_input, wacom_wac->touch_input);
}
@@ -2793,16 +2804,19 @@ static void wacom_mode_change_work(struct work_struct *work)
bool is_direct = wacom->wacom_wac.is_direct_mode;
int error = 0;
- if (shared->pen) {
- wacom1 = hid_get_drvdata(shared->pen);
+ struct hid_device *pen = rcu_access_pointer(shared->pen);
+ struct hid_device *touch = rcu_access_pointer(shared->touch);
+
+ if (pen) {
+ wacom1 = hid_get_drvdata(pen);
wacom_release_resources(wacom1);
hid_hw_stop(wacom1->hdev);
wacom1->wacom_wac.has_mode_change = true;
wacom1->wacom_wac.is_direct_mode = is_direct;
}
- if (shared->touch) {
- wacom2 = hid_get_drvdata(shared->touch);
+ if (touch) {
+ wacom2 = hid_get_drvdata(touch);
wacom_release_resources(wacom2);
hid_hw_stop(wacom2->hdev);
wacom2->wacom_wac.has_mode_change = true;
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 4ac4d0c19461..821eb0027730 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3294,6 +3294,7 @@ static int wacom_bpt_irq(struct wacom_wac *wacom, size_t len)
static void wacom_bamboo_pad_pen_event(struct wacom_wac *wacom,
unsigned char *data)
{
+ struct hid_device *pen;
unsigned char prefix;
/*
@@ -3306,13 +3307,11 @@ static void wacom_bamboo_pad_pen_event(struct wacom_wac *wacom,
prefix = data[0];
data[0] = WACOM_REPORT_BPAD_PEN;
- /*
- * actually reroute the event.
- * No need to check if wacom->shared->pen is valid, hid_input_report()
- * will check for us.
- */
- hid_input_report(wacom->shared->pen, HID_INPUT_REPORT, data,
- WACOM_PKGLEN_PENABLED, 1);
+ guard(rcu)();
+ pen = rcu_dereference(wacom->shared->pen);
+ if (pen)
+ hid_input_report(pen, HID_INPUT_REPORT, data,
+ WACOM_PKGLEN_PENABLED, 1);
data[0] = prefix;
}
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index a8bbba4a6f37..170d6adbe02a 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -286,8 +286,8 @@ struct wacom_shared {
unsigned touch_max;
int type;
struct input_dev __rcu *touch_input;
- struct hid_device *pen;
- struct hid_device *touch;
+ struct hid_device __rcu *pen;
+ struct hid_device __rcu *touch;
bool has_mute_touch_switch;
bool is_touch_on;
};
--
2.55.0.141.g00534a21ce-goog
^ permalink raw reply related
* [PATCH v6 2/4] HID: wacom: Fix Use-After-Free in wacom_intuos_pad
From: Lee Jones @ 2026-07-16 9:07 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Aaron Skomra, Dmitry Torokhov, Peter Hutterer, linux-input,
linux-kernel
In-Reply-To: <20260716090726.2711293-1-lee@kernel.org>
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.
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
drivers/hid/wacom_sys.c | 35 +++++++++++++++++++++++------------
drivers/hid/wacom_wac.c | 36 ++++++++++++++++++------------------
drivers/hid/wacom_wac.h | 2 +-
3 files changed, 42 insertions(+), 31 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 6c2a3ddfe366..c6b37931d02d 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -875,10 +875,16 @@ static void wacom_remove_shared_data(void *res)
data = container_of(wacom_wac->shared, struct wacom_hdev_data,
shared);
- if (wacom_wac->shared->touch == wacom->hdev)
- wacom_wac->shared->touch = NULL;
- else if (wacom_wac->shared->pen == wacom->hdev)
- wacom_wac->shared->pen = NULL;
+ scoped_guard(mutex, &wacom_udev_list_lock) {
+ if (wacom_wac->shared->touch == wacom->hdev) {
+ wacom_wac->shared->touch = NULL;
+ rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
+ } else if (wacom_wac->shared->pen == wacom->hdev) {
+ wacom_wac->shared->pen = NULL;
+ }
+ }
+
+ synchronize_rcu();
kref_put(&data->kref, wacom_release_shared_data);
wacom_wac->shared = NULL;
@@ -907,6 +913,11 @@ static int wacom_add_shared_data(struct hid_device *hdev)
list_add_tail(&data->list, &wacom_udev_list);
}
+ if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
+ data->shared.touch = hdev;
+ else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
+ data->shared.pen = hdev;
+
mutex_unlock(&wacom_udev_list_lock);
wacom_wac->shared = &data->shared;
@@ -915,11 +926,6 @@ static int wacom_add_shared_data(struct hid_device *hdev)
if (retval)
return retval;
- if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
- wacom_wac->shared->touch = hdev;
- else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
- wacom_wac->shared->pen = hdev;
-
return retval;
}
@@ -2343,9 +2349,15 @@ static void wacom_release_resources(struct wacom *wacom)
static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
{
+ struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+
+ guard(mutex)(&wacom_udev_list_lock);
+
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;
+ if (wacom_wac->shared->touch == wacom->hdev) {
+ wacom_wac->shared->type = wacom_wac->features.type;
+ rcu_assign_pointer(wacom_wac->shared->touch_input, wacom_wac->touch_input);
+ }
}
if (wacom_wac->has_mute_touch_switch) {
@@ -2358,7 +2370,6 @@ static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
if (wacom_wac->is_soft_touch_switch)
wacom_wac->shared->is_touch_on = true;
}
-
}
static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 32c4fd03479e..4ac4d0c19461 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -510,6 +510,18 @@ static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
}
}
+static void wacom_report_touch_mute(struct wacom_wac *wacom_wac, bool mute)
+{
+ struct input_dev *touch_input;
+
+ guard(rcu)();
+ touch_input = rcu_dereference(wacom_wac->shared->touch_input);
+ if (touch_input) {
+ input_report_switch(touch_input, SW_MUTE_DEVICE, mute);
+ input_sync(touch_input);
+ }
+}
+
static int wacom_intuos_pad(struct wacom_wac *wacom)
{
struct wacom_features *features = &wacom->features;
@@ -650,12 +662,8 @@ static int wacom_intuos_pad(struct wacom_wac *wacom)
input_report_key(input, KEY_CONTROLPANEL, menu);
input_report_key(input, KEY_INFO, info);
- 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);
- }
+ if (wacom->shared)
+ wacom_report_touch_mute(wacom, !wacom->shared->is_touch_on);
input_report_abs(input, ABS_RX, strip1);
input_report_abs(input, ABS_RY, strip2);
@@ -2155,7 +2163,7 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
*/
if ((equivalent_usage == WACOM_HID_WD_MUTE_DEVICE) ||
(equivalent_usage == WACOM_HID_WD_TOUCHONOFF)) {
- if (wacom_wac->shared->touch_input) {
+ if (wacom_wac->shared) {
bool *is_touch_on = &wacom_wac->shared->is_touch_on;
if (equivalent_usage == WACOM_HID_WD_MUTE_DEVICE && value)
@@ -2163,9 +2171,7 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
else if (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)
*is_touch_on = value;
- input_report_switch(wacom_wac->shared->touch_input,
- SW_MUTE_DEVICE, !(*is_touch_on));
- input_sync(wacom_wac->shared->touch_input);
+ wacom_report_touch_mute(wacom_wac, !(*is_touch_on));
}
return;
}
@@ -3383,11 +3389,8 @@ static int wacom_wireless_irq(struct wacom_wac *wacom, size_t len)
if ((wacom->shared->type == INTUOSHT ||
wacom->shared->type == INTUOSHT2) &&
- wacom->shared->touch_input &&
wacom->shared->touch_max) {
- input_report_switch(wacom->shared->touch_input,
- SW_MUTE_DEVICE, data[5] & 0x40);
- input_sync(wacom->shared->touch_input);
+ wacom_report_touch_mute(wacom, data[5] & 0x40);
}
pid = get_unaligned_be16(&data[6]);
@@ -3422,11 +3425,8 @@ static int wacom_status_irq(struct wacom_wac *wacom_wac, size_t len)
if ((features->type == INTUOSHT ||
features->type == INTUOSHT2) &&
- wacom_wac->shared->touch_input &&
features->touch_max) {
- input_report_switch(wacom_wac->shared->touch_input,
- SW_MUTE_DEVICE, data[8] & 0x40);
- input_sync(wacom_wac->shared->touch_input);
+ wacom_report_touch_mute(wacom_wac, data[8] & 0x40);
}
if (data[9] & 0x02) { /* wireless module is attached */
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 126bec6e5c0c..a8bbba4a6f37 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -285,7 +285,7 @@ struct wacom_shared {
/* for wireless device to access USB interfaces */
unsigned touch_max;
int type;
- struct input_dev *touch_input;
+ struct input_dev __rcu *touch_input;
struct hid_device *pen;
struct hid_device *touch;
bool has_mute_touch_switch;
--
2.55.0.141.g00534a21ce-goog
^ permalink raw reply related
* [PATCH v6 1/4] HID: wacom: Advertise SW_MUTE_DEVICE capability prior to registration
From: Lee Jones @ 2026-07-16 9:07 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Aaron Skomra, Dmitry Torokhov, Peter Hutterer, linux-input,
linux-kernel
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, excluding TabletPC devices.
Additionally, replace the lookup-dependent
'wacom_wac->shared->touch->product' references with 'hdev->product'
inside wacom_setup_touch_input_capabilities() as 'hdev' is already
available and represents the touch device itself.
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
drivers/hid/wacom_sys.c | 6 ------
drivers/hid/wacom_wac.c | 19 +++++++++++--------
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 0eafa483b7f7..6c2a3ddfe366 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2359,12 +2359,6 @@ 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);
- }
}
static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index a29bf051ada7..32c4fd03479e 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3953,6 +3953,8 @@ int wacom_setup_pen_input_capabilities(struct input_dev *input_dev,
int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
struct wacom_wac *wacom_wac)
{
+ struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+ struct hid_device *hdev = wacom->hdev;
struct wacom_features *features = &wacom_wac->features;
if (!(features->device_type & WACOM_DEVICETYPE_TOUCH))
@@ -3963,9 +3965,12 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
else
__set_bit(INPUT_PROP_POINTER, input_dev->propbit);
- if (features->type == HID_GENERIC)
+ if (features->type == HID_GENERIC) {
+ input_dev->evbit[0] |= BIT_MASK(EV_SW);
+ __set_bit(SW_MUTE_DEVICE, input_dev->swbit);
/* setup has already been done */
return 0;
+ }
input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
__set_bit(BTN_TOUCH, input_dev->keybit);
@@ -3997,19 +4002,17 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
input_dev->evbit[0] |= BIT_MASK(EV_SW);
__set_bit(SW_MUTE_DEVICE, input_dev->swbit);
- if (wacom_wac->shared->touch->product == 0x361) {
+ if (hdev->product == 0x361) {
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, 12440, 4, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
0, 8640, 4, 0);
- }
- else if (wacom_wac->shared->touch->product == 0x360) {
+ } else if (hdev->product == 0x360) {
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, 8960, 4, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
0, 5920, 4, 0);
- }
- else if (wacom_wac->shared->touch->product == 0x393) {
+ } else if (hdev->product == 0x393) {
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, 6400, 4, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
@@ -4039,8 +4042,8 @@ int wacom_setup_touch_input_capabilities(struct input_dev *input_dev,
fallthrough;
case WACOM_27QHDT:
- if (wacom_wac->shared->touch->product == 0x32C ||
- wacom_wac->shared->touch->product == 0xF6) {
+ if (hdev->product == 0x32C ||
+ hdev->product == 0xF6) {
input_dev->evbit[0] |= BIT_MASK(EV_SW);
__set_bit(SW_MUTE_DEVICE, input_dev->swbit);
wacom_wac->has_mute_touch_switch = true;
--
2.55.0.141.g00534a21ce-goog
^ permalink raw reply related
* Re: [PATCH v2 4/4] HID: Intel-thc-hid: Remove redundant dev_err()
From: sashiko-bot @ 2026-07-16 8:33 UTC (permalink / raw)
To: Pan Chuang; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260716075203.593012-5-panchuang@vivo.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Device removal manually frees non-devm DMA scatterlist buffers before disabling hardware interrupts and the threaded IRQ handler, leading to a Use-After-Free.
- [High] The primary interrupt handlers unconditionally return `IRQ_HANDLED` when the device is in the `DISABLED` state, without checking the hardware interrupt source or clearing the interrupt condition.
--
--- Patch [4]: [PATCH v2 4/4] HID: Intel-thc-hid: Remove redundant dev_err() ---
commit d99357f50f34b4097b4c3b9ec6cfab0677cc831e
Author: Pan Chuang <panchuang@vivo.com>
Subject: HID: Intel-thc-hid: Remove redundant dev_err()
This commit removes redundant driver-specific dev_err calls following
devm_request_threaded_irq failures, as detailed error messages are already
logged by the core subsystem on failure.
> diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> index 46d3e9a019995..59f500345acbf 100644
> --- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> +++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
> @@ -682,11 +682,8 @@ static int quicki2c_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> quicki2c_irq_thread_handler,
> IRQF_ONESHOT, KBUILD_MODNAME,
> qcdev);
[Severity: High]
This is a pre-existing issue, but while we are touching the threaded IRQ
setup, does quicki2c_irq_quick_handler() properly handle shared INTx
interrupts?
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c:quicki2c_irq_quick_handler() {
...
if (qcdev->state == QUICKI2C_DISABLED)
return IRQ_HANDLED;
...
}
The device initializes with PCI_IRQ_ALL_TYPES, allowing fallback to INTx.
If an interrupt fires when the device state is QUICKI2C_DISABLED, the
handler unconditionally returns IRQ_HANDLED without clearing the hardware
condition. Could this prevent the generic IRQ subsystem from detecting and
disabling spurious interrupts, resulting in an interrupt storm?
[Severity: Critical]
This is a pre-existing issue, but does relying on a devm-managed IRQ here
cause a use-after-free regression during driver unbind?
During driver unbind, quicki2c_remove() explicitly frees non-devm DMA
scatterlist buffers before the devm framework tears down this IRQ:
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c:quicki2c_remove() {
...
quicki2c_dma_deinit(qcdev);
pm_runtime_get_noresume(qcdev->dev);
quicki2c_dev_deinit(qcdev);
...
}
Because devres cleans up the IRQ only after remove() returns, and hardware
interrupts are disabled later in quicki2c_dev_deinit(), the IRQ can still
fire after quicki2c_dma_deinit() unmaps and frees the scatterlist arrays.
If a concurrent hardware interrupt fires, the unlocked read_dma_buffer()
might access the freed scatterlists:
drivers/hid/intel-thc-hid/intel-thc/intel-thc-dma.c:read_dma_buffer() {
...
sg = read_config->sgls[prd_table_index];
ret = sg_copy_to_buffer(sg, nent, read_buff, mes_len);
...
}
Can this lead to memory corruption if the handler executes on freed memory?
> - if (ret) {
> - dev_err_once(&pdev->dev,
> - "Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
> + if (ret)
> goto dev_deinit;
> - }
[ ... ]
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> index 4ae2e1718b30c..504ef3c842ab6 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
> @@ -636,11 +636,8 @@ static int quickspi_probe(struct pci_dev *pdev,
> quickspi_irq_thread_handler,
> IRQF_ONESHOT, KBUILD_MODNAME,
> qsdev);
[Severity: High]
This isn't a bug introduced by this patch, but does the same regression
regarding shared INTx interrupts exist in quickspi_irq_quick_handler()?
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c:quickspi_irq_quick_handler() {
...
if (qsdev->state == QUICKSPI_DISABLED)
return IRQ_HANDLED;
...
}
Returning IRQ_HANDLED without clearing the hardware condition might cause
an interrupt storm if the IRQ line is shared.
[Severity: Critical]
This is a pre-existing issue, but does the same use-after-free pattern
exist here during QuickSPI device removal?
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c:quickspi_remove() {
...
quickspi_dma_deinit(qsdev);
pm_runtime_get_noresume(qsdev->dev);
quickspi_dev_deinit(qsdev);
...
}
The devm-managed IRQ will remain active after quickspi_dma_deinit() frees
the scatterlists. Could a concurrent interrupt corrupt memory?
> - if (ret) {
> - dev_err(&pdev->dev,
> - "Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
> + if (ret)
> goto dev_deinit;
> - }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716075203.593012-1-panchuang@vivo.com?part=4
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: intel-ish-hid: ipc: Remove redundant dev_err()
From: sashiko-bot @ 2026-07-16 8:17 UTC (permalink / raw)
To: Pan Chuang; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260716075203.593012-4-panchuang@vivo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing call to `pci_free_irq_vectors()` in the error paths of `ish_probe()` after a successful `pci_alloc_irq_vectors()`.
--
--- Patch [3]: [PATCH v2 3/4] HID: intel-ish-hid: ipc: Remove redundant dev_err() ---
commit e6d17c39d85bf24754ef698f7e6d06f53c4283e2
Author: Pan Chuang <panchuang@vivo.com>
HID: intel-ish-hid: ipc: Remove redundant dev_err()
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index ed3405c05e73c..cef1030643f15 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -232,10 +232,8 @@ static int ish_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> ret = devm_request_irq(dev, pdev->irq, ish_irq_handler,
> irq_flag, KBUILD_MODNAME, ishtp);
> - if (ret) {
> - dev_err(dev, "ISH: request IRQ %d failed\n", pdev->irq);
> + if (ret)
> return ret;
[Severity: High]
This is a pre-existing issue, but does this error path leak the IRQ vectors
allocated earlier in ish_probe()?
If devm_request_irq() fails, the function returns directly. Similarly, if
ish_init() fails further down in ish_probe(), it also returns directly:
ret = ish_init(ishtp);
if (ret)
return ret;
Should there be a call to pci_free_irq_vectors() in these error paths
since pci_alloc_irq_vectors() was successfully called previously?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260716075203.593012-1-panchuang@vivo.com?part=3
^ permalink raw reply
* [PATCH v2 4/4] HID: Intel-thc-hid: Remove redundant dev_err()
From: Pan Chuang @ 2026-07-16 7:51 UTC (permalink / raw)
To: Even Xu, Xinpeng Sun, Jiri Kosina, Benjamin Tissoires,
Sakari Ailus, Pan Chuang, Abhishek Tamboli, Danny D.,
open list:HID CORE LAYER, open list
In-Reply-To: <20260716075203.593012-1-panchuang@vivo.com>
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_threaded_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
---
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 5 +----
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 5 +----
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index 46d3e9a01999..59f500345acb 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -682,11 +682,8 @@ static int quicki2c_probe(struct pci_dev *pdev, const struct pci_device_id *id)
quicki2c_irq_thread_handler,
IRQF_ONESHOT, KBUILD_MODNAME,
qcdev);
- if (ret) {
- dev_err_once(&pdev->dev,
- "Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
+ if (ret)
goto dev_deinit;
- }
ret = quicki2c_get_device_descriptor(qcdev);
if (ret) {
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index 4ae2e1718b30..504ef3c842ab 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -636,11 +636,8 @@ static int quickspi_probe(struct pci_dev *pdev,
quickspi_irq_thread_handler,
IRQF_ONESHOT, KBUILD_MODNAME,
qsdev);
- if (ret) {
- dev_err(&pdev->dev,
- "Failed to request threaded IRQ, irq = %d.\n", pdev->irq);
+ if (ret)
goto dev_deinit;
- }
ret = reset_tic(qsdev);
if (ret) {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] HID: intel-ish-hid: ipc: Remove redundant dev_err()
From: Pan Chuang @ 2026-07-16 7:51 UTC (permalink / raw)
To: Srinivas Pandruvada, Jiri Kosina, Benjamin Tissoires, Zhang Lixu,
Andy Shevchenko, Vineeth Pillai, Pan Chuang,
open list:INTEL INTEGRATED SENSOR HUB DRIVER, open list
In-Reply-To: <20260716075203.593012-1-panchuang@vivo.com>
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 8d36ae96a3ee..e7196e429c8b 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -232,10 +232,8 @@ static int ish_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
ret = devm_request_irq(dev, pdev->irq, ish_irq_handler,
irq_flag, KBUILD_MODNAME, ishtp);
- if (ret) {
- dev_err(dev, "ISH: request IRQ %d failed\n", pdev->irq);
+ if (ret)
return ret;
- }
dev_set_drvdata(ishtp->devc, ishtp);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] HID: hid-goodix: Remove redundant dev_err()
From: Pan Chuang @ 2026-07-16 7:51 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, open list:HID CORE LAYER,
open list
Cc: Pan Chuang
In-Reply-To: <20260716075203.593012-1-panchuang@vivo.com>
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_threaded_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
---
drivers/hid/hid-goodix-spi.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/hid/hid-goodix-spi.c b/drivers/hid/hid-goodix-spi.c
index 288cb827e9d6..03d549efbdce 100644
--- a/drivers/hid/hid-goodix-spi.c
+++ b/drivers/hid/hid-goodix-spi.c
@@ -722,11 +722,8 @@ static int goodix_spi_probe(struct spi_device *spi)
error = devm_request_threaded_irq(&ts->spi->dev, ts->spi->irq,
NULL, goodix_hid_irq, IRQF_ONESHOT,
"goodix_spi_hid", ts);
- if (error) {
- dev_err(ts->dev, "could not register interrupt, irq = %d, %d",
- ts->spi->irq, error);
+ if (error)
goto err_destroy_hid;
- }
return 0;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/4] HID: amd_sfh: Remove redundant dev_err()
From: Pan Chuang @ 2026-07-16 7:51 UTC (permalink / raw)
To: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
open list:AMD SENSOR FUSION HUB DRIVER, open list
Cc: Pan Chuang
In-Reply-To: <20260716075203.593012-1-panchuang@vivo.com>
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() automatically logs
detailed error messages on failure. Remove the now-redundant
driver-specific dev_err() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
---
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 4b81cebdc335..a2acd3ca20e2 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -128,11 +128,8 @@ int amd_sfh_irq_init_v2(struct amd_mp2_dev *privdata)
rc = devm_request_irq(&privdata->pdev->dev, privdata->pdev->irq,
amd_sfh_irq_handler, 0, DRIVER_NAME, privdata);
- if (rc) {
- dev_err(&privdata->pdev->dev, "failed to request irq %d err=%d\n",
- privdata->pdev->irq, rc);
+ if (rc)
return rc;
- }
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/4] HID: Remove redundant error messages on IRQ request failure
From: Pan Chuang @ 2026-07-16 7:51 UTC (permalink / raw)
To: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, Even Xu, Xinpeng Sun, Zhang Lixu,
Andy Shevchenko, Vineeth Pillai, Pan Chuang, Sakari Ailus,
Abhishek Tamboli, Danny D.,
open list:AMD SENSOR FUSION HUB DRIVER, open list
Commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()") added automatic error logging to
devm_request_threaded_irq() and devm_request_any_context_irq()
via the new devm_request_result() helper, which prints device
name, IRQ number, handler functions, and error code on failure.
Since devm_request_irq() is a static inline wrapper around
devm_request_threaded_irq(), it also benefits from this
automatic logging.
Remove the now-redundant dev_err() and dev_err_probe() calls
in hid drivers that follow these devm_request_*_irq()
functions, as the core now provides more detailed diagnostic
information on failure.
v1 -> v2:
- Added the same change for the intel-quicki2c driver
Pan Chuang (4):
HID: amd_sfh: Remove redundant dev_err()
HID: hid-goodix: Remove redundant dev_err()
HID: intel-ish-hid: ipc: Remove redundant dev_err()
HID: Intel-thc-hid: Remove redundant dev_err()
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 5 +----
drivers/hid/hid-goodix-spi.c | 5 +----
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 4 +---
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 5 +----
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 5 +----
5 files changed, 5 insertions(+), 19 deletions(-)
--
2.34.1
^ permalink raw reply
* RE: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: Zhang, Lixu @ 2026-07-16 6:11 UTC (permalink / raw)
To: Wahid7852, linux-input@vger.kernel.org
Cc: jikos@kernel.org, srinivas pandruvada
In-Reply-To: <dd9ced1905adb4805916b173847282ff168a66b9.camel@linux.intel.com>
>-----Original Message-----
>From: Zhang, Lixu
>Sent: Wednesday, July 1, 2026 11:20 AM
>To: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>; Wahid7852
><wahidzk0091@gmail.com>; linux-input@vger.kernel.org
>Cc: jikos@kernel.org
>Subject: RE: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from
>firmware
>
>>-----Original Message-----
>>From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>>Sent: Tuesday, June 30, 2026 1:35 AM
>>To: Wahid7852 <wahidzk0091@gmail.com>; linux-input@vger.kernel.org;
>>Zhang, Lixu <lixu.zhang@intel.com>
>>Cc: jikos@kernel.org
>>Subject: Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES
>>from firmware
>>
>>+Lixu
>
>Thanks for your patch. I'll do some power cycle tests and provide feedback
>when I have some free time.
Hi Wahid,
I completed power-cycle testing on ARL and NVL platforms and found no regressions. Please go ahead and send v2.
Best regard,
Lixu
>
>Best regards,
>Lixu
>
^ permalink raw reply
* [PATCH RESEND] HID: corsair: fix typos in comment
From: Owen Giles @ 2026-07-16 5:19 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, Owen Giles
In-Reply-To: <20260118185815.14237-1-owen.a.giles@gmail.com>
Fix typos in report descriptor comment: "obviousy" -> "obviously",
"Magimum" -> "Maximum", "poper" -> "proper", "due Logical" -> "due to
Logical".
Signed-off-by: Owen Giles <owen.a.giles@gmail.com>
---
drivers/hid/hid-corsair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-corsair.c b/drivers/hid/hid-corsair.c
index 21cd8b12a..82bccaf1d 100644
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -681,8 +681,8 @@ static int corsair_input_mapping(struct hid_device *dev,
* The report descriptor of some of the Corsair gaming mice is
* non parseable as they define two consecutive Logical Minimum for
* the Usage Page (Consumer) in rdescs bytes 75 and 77 being 77 0x16
- * that should be obviousy 0x26 for Logical Magimum of 16 bits. This
- * prevents poper parsing of the report descriptor due Logical
+ * that should be obviously 0x26 for Logical Maximum of 16 bits. This
+ * prevents proper parsing of the report descriptor due to Logical
* Minimum being larger than Logical Maximum.
*
* This driver fixes the report descriptor for:
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] Input: wacom_w8001 - replace strlcat() with a strscpy() helper
From: Dmitry Torokhov @ 2026-07-16 1:39 UTC (permalink / raw)
To: Ian Bridges; +Cc: linux-input, linux-kernel, linux-hardening
In-Reply-To: <albg4Rv7QxvLJD05@dev>
On Tue, Jul 14, 2026 at 08:22:41PM -0500, Ian Bridges wrote:
> In preparation for removing the strlcat() API[1], replace its five
> uses with a small append helper built on strnlen() and strscpy().
>
> The five calls append device name fragments to a basename buffer
> that grows in place across the setup functions. The helper takes
> the same arguments as strlcat() and writes the same bytes, including
> when a fragment is truncated.
>
> Link: https://github.com/KSPP/linux/issues/370 [1]
> Signed-off-by: Ian Bridges <icb@fastmail.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()
From: Alec Hall @ 2026-07-15 23:04 UTC (permalink / raw)
To: Jose Villaseñor Montfort, linux-input
Cc: Jiri Kosina, Benjamin Tissoires, linux-kernel, Alec Hall
In-Reply-To: <20260715053526.574725-1-pepemontfort@gmail.com>
On Tue, Jul 14, 2026, Jose Villaseñor Montfort wrote:
> A double report only ever wraps two normal reports; it is never
> legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a
> recursive call so the recursion depth is bounded to two [...]
Reviewed the logic: gating re-entry into the DOUBLE_REPORT_ID case on the
new "nested" flag caps recursion at two levels, and since a legitimate
double only ever wraps two non-double reports, valid traffic parses
exactly as before. The guard placement (before the size checks and the
split) and the wrapper preserving the callback signature both look right.
I also stacked this on top of the pending Magic Keyboard/Trackpad battery
series and ran it on a Magic Trackpad 2 over Bluetooth: normal pointer plus
multi-finger gestures (which drive the DOUBLE_REPORT_ID path), and battery
reporting, all keep working with no regressions or splats in dmesg.
Reviewed-by: Alec Hall <signshop.alec@gmail.com>
Tested-by: Alec Hall <signshop.alec@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] HID: magicmouse: report charge status over Bluetooth
From: Alec Hall @ 2026-07-15 22:18 UTC (permalink / raw)
To: Jose Villaseñor Montfort, linux-input
Cc: Jiri Kosina, Benjamin Tissoires, linux-kernel, Alec Hall
In-Reply-To: <20260715200354.1307250-1-pepemontfort@gmail.com>
Hi Jose,
Great -- doing it in magicmouse_probe() is the better fix. Moving the
"input not registered" check ahead of the early return rejects the bad
device up front and covers both ->raw_event and ->event, which is cleaner
than a guard in the hot path. No need for me to take it; please keep it.
I'll review both patches and give them a run on my hardware (Magic Keyboard
2021 and Magic Trackpad 2 over Bluetooth) to confirm the normal
enumeration and battery path is unaffected, and follow up with
Reviewed-by/Tested-by on the respective threads.
Agreed on the rebase too -- if yours land first I'll just relocate the 3/3
report-check hunk into the new wrapper.
Thanks for taking both of these,
Alec
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox