* [PATCH v4 3/6] iio: light: HID: hid-sensor-als: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local als_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/light/hid-sensor-als.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 384572844162..d72e260b8266 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -117,17 +118,6 @@ static const struct iio_chan_spec als_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void als_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int als_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -335,7 +325,11 @@ static int als_parse_report(struct platform_device *pdev,
channels[index] = als_channels[i];
st->als_scan_mask[0] |= BIT(i);
- als_adjust_channel_bit_mask(channels, index, st->als[i].size);
+ channels[index].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->als[i].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
++index;
dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/6] iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local gyro_3d_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability. Additionaly, clean up the channel initialization
loop by iterating directly over the channel scan indices.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 27 +++++++++------------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index c340cc899a7c..e48c25c87b6d 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -82,17 +83,6 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void gyro_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int gyro_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -248,19 +238,20 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
struct gyro_3d_state *st)
{
int ret;
- int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id,
- HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + i,
- &st->gyro[CHANNEL_SCAN_INDEX_X + i]);
+ HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
+ &st->gyro[ch]);
if (ret < 0)
break;
- gyro_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->gyro[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->gyro[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "gyro_3d %x:%x, %x:%x, %x:%x\n",
st->gyro[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/6] iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Clean up the channel initialization loop and replace the local
accel_3d_adjust_channel_bit_mask() function with a compound literal
to improve code readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++++----------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 2ff591b3458f..2bf05ab5235e 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -119,17 +120,6 @@ static const struct iio_chan_spec gravity_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP),
};
-/* Adjust channel real bits based on report descriptor */
-static void accel_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int accel_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -297,19 +287,20 @@ static int accel_3d_parse_report(struct platform_device *pdev,
struct accel_3d_state *st)
{
int ret;
- int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id,
- HID_USAGE_SENSOR_ACCEL_X_AXIS + i,
- &st->accel[CHANNEL_SCAN_INDEX_X + i]);
+ HID_USAGE_SENSOR_ACCEL_X_AXIS + ch,
+ &st->accel[ch]);
if (ret < 0)
break;
- accel_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->accel[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->accel[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "accel_3d %x:%x, %x:%x, %x:%x\n",
st->accel[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/6] iio: hid-sensor: standardize scan_type initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, linux-iio, linux-input
This series refactors the HID sensor drivers to standardize the
initialization of the iio_chan_spec scan_type structure using compound
literals.
This change improves code readability and ensures that all fields of
the scan_type structure are properly zero-initialized, allowing the
removal of local helper functions.
Additionally, the channel initialization loops for hid-sensor-accel-3d
and hid-sensor-gyro-3d were cleaned up to iterate directly over the
scan indices, eliminating redundant index-offset logic.
---
Changes in v4:
- Fixed a bug in the sensor_hub_input_get_attribute_info()
call where passing the raw loop index 'ch' broke the HID report
field lookup in hid-sensor-accel-3d. Restored the proper HID
usage ID offset calculation using HID_USAGE_SENSOR_ACCEL_X_AXIS + ch
- Cleaned up the channel initialization loop to iterate
directly over the scan indices in hid-sensor-gyro-3d for consistency
Changes in v3:
- Dropped the global helper function implementation from
hid-sensor-attributes.c following maintainer feedback.
- Shifted to local refactoring inside the drivers using compound
literals and the macros BYTES_TO_BITS() and BITS_PER_TYPE()
- Refactored the channel initialization loop in hid-sensor-accel-3d to
iterate directly over the scan enums instead of using 0-based
index offsets
- v3 link: https://lore.kernel.org/linux-iio/89a2e6775e3c922a4848a4b4730aab8d32097454.camel@linux.intel.com/T/#t
Changes in v2:
- Modified the helper function to use the BITS_PER_BYTE macro instead of
magic numbers for bit calculations
- Updated the scan_type structure field assignment from '.sign'
to '.format' based on recent subsystem renaming feedback
Natália Salvino André (6):
iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
iio: light: HID: hid-sensor-als: Refactor channel initialization
iio: light: HID: hid-sensor-prox: Refactor channel initialization
iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
initialization
iio: pressure: HID: hid-sensor-press: Refactor channel initialization
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
drivers/iio/gyro/hid-sensor-gyro-3d.c | 27 +++++++------------
drivers/iio/light/hid-sensor-als.c | 18 +++++--------
drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
6 files changed, 42 insertions(+), 88 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: Mismatched product ids for the ASUS ROG RAIKIRI PRO
From: Dmitry Torokhov @ 2026-05-19 21:18 UTC (permalink / raw)
To: Justin Opini; +Cc: linux-input, linux-kernel, torvalds, Luke D. Jones
In-Reply-To: <20260519173800.6765-1-opinijm@provdh.com>
Hi Justin,
On Tue, May 19, 2026 at 01:37:59PM -0400, Justin Opini wrote:
> Hey Dimity,
>
> I had a question on the product id,
> { 0x0b05, 0x1abb, "ASUS ROG RAIKIRI PRO", 0, XTYPE_XBOXONE },
>
> This doesn’t match both my devices so I was wondering if somehow we
> have similar named devices with need for different product ids or if
> there was a mistake in the original commit?
>
> My relevant entries from lsusb are
> Bus 001 Device 002: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
> Bus 001 Device 003: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
>
> On my system I have ended up using this udev rule for quite some time
> ACTION=="add", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1a3c", GROUP="input", MODE="0660", TAG+="uaccess", TAG+="seat", RUN+="/bin/sh -c 'echo 0b05 1a3c > /sys/bus/usb/drivers/xpad/new_id'"
I am CC-ing Luke who added this VID/PID comboi to double check, but it
looks like there are many variants of this controller using the same
"ROG RAIKIRI PRO" name. For example
https://github.com/atar-axis/xpadneo/issues/612 talks about
0x0b05/0x1abd.
Thanks.
--
Dmitry
^ permalink raw reply
* [syzbot] [fs?] [usb?] [input?] INFO: rcu detected stall in __fsnotify_parent (3)
From: syzbot @ 2026-05-19 20:54 UTC (permalink / raw)
To: amir73il, jack, linux-fsdevel, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 6916d5703ddf Merge tag 'drm-fixes-2026-05-16' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13437cc8580000
kernel config: https://syzkaller.appspot.com/x/.config?x=59da38148f3a3d24
dashboard link: https://syzkaller.appspot.com/bug?extid=27ce6cc06c1311c152f5
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123e8596580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/637181391a5c/disk-6916d570.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bfbefc8a3671/vmlinux-6916d570.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a419831b32a6/bzImage-6916d570.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+27ce6cc06c1311c152f5@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P4963/1:b..l
rcu: (detected by 1, t=10506 jiffies, g=15565, q=1900 ncpus=2)
task:acpid state:R
running task stack:22856 pid:4963 tgid:4963 ppid:1 task_flags:0x400040 flags:0x00080001
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5388 [inline]
__schedule+0x1295/0x67a0 kernel/sched/core.c:7189
preempt_schedule_irq+0x50/0x90 kernel/sched/core.c:7513
irqentry_exit_to_kernel_mode_preempt include/linux/irq-entry-common.h:476 [inline]
irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:547 [inline]
irqentry_exit+0x205/0x7e0 kernel/entry/common.c:164
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_acquire+0x5e/0x370 kernel/locking/lockdep.c:5872
Code: 05 3b a2 26 12 83 f8 07 0f 87 d9 02 00 00 48 0f a3 05 46 41 f3 0e 0f 82 a4 02 00 00 8b 35 ce 74 f3 0e 85 f6 0f 85 bf 00 00 00 <48> 8b 44 24 30 65 48 2b 05 dd a1 26 12 0f 85 ed 02 00 00 48 83 c4
RSP: 0018:ffffc9000342fb30 EFLAGS: 00000206
RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8defcf06 RDI: ffffffff8c1c3a00
RBP: ffffffff8e7e57a0 R08: 0000000086db7919 R09: 0000000000000007
R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
rcu_read_lock include/linux/rcupdate.h:838 [inline]
dput.part.0+0x4c/0x570 fs/dcache.c:971
dput+0x1f/0x30 fs/dcache.c:968
__fsnotify_parent+0x694/0xca0 fs/notify/fsnotify.c:242
fsnotify_parent include/linux/fsnotify.h:96 [inline]
fsnotify_path include/linux/fsnotify.h:113 [inline]
fsnotify_file include/linux/fsnotify.h:127 [inline]
fsnotify_file include/linux/fsnotify.h:116 [inline]
fsnotify_access include/linux/fsnotify.h:425 [inline]
vfs_read+0x486/0xb30 fs/read_write.c:578
ksys_read+0x1f8/0x250 fs/read_write.c:717
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x10b/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7feac7fb3407
RSP: 002b:00007ffc6dd51e00 EFLAGS: 00000202
ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007feac7f29780 RCX: 00007feac7fb3407
RDX: 0000000000000018 RSI: 00007ffc6dd51e50 RDI: 000000000000000b
RBP: 00007ffc6dd51e50 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000556e2f8031e4
R13: 0000556e4a9f2380 R14: 0000000000000007 R15: 000000000000000b
</TASK>
rcu: rcu_preempt kthread starved for 4298 jiffies! g15565 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R
running task stack:27992 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5388 [inline]
__schedule+0x1295/0x67a0 kernel/sched/core.c:7189
__schedule_loop kernel/sched/core.c:7268 [inline]
schedule+0xdd/0x390 kernel/sched/core.c:7283
schedule_timeout+0x127/0x280 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x1a9/0x900 kernel/rcu/tree.c:2095
rcu_gp_kthread+0x179/0x230 kernel/rcu/tree.c:2297
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
CPU: 1 UID: 0 PID: 5978 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:write_comp_data+0x40/0x90 kernel/kcov.c:246
Code: 02 12 a9 00 01 ff 00 74 1b f6 c4 01 74 07 a9 00 00 ff 00 74 05 c3 cc cc cc cc 8b 87 d4 16 00 00 85 c0 74 f1 8b 87 b0 16 00 00 <83> f8 03 75 e6 48 8b 87 b8 16 00 00 8b bf b4 16 00 00 48 8b 30 48
RSP: 0018:ffffc900024af648 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff81fc2bcd
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88805a5e0000
RBP: ffff8880b8443320 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000003
R13: ffffed1017088665 R14: 0000000000000001 R15: ffff8880b853c5c0
FS: 0000000000000000(0000) GS:ffff88812446d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8c6e1b56e8 CR3: 0000000059a89000 CR4: 00000000003526f0
Call Trace:
<TASK>
csd_lock_wait kernel/smp.c:342 [inline]
smp_call_function_many_cond+0x5ad/0x1700 kernel/smp.c:892
on_each_cpu_cond_mask+0x40/0x90 kernel/smp.c:1057
__flush_tlb_multi arch/x86/include/asm/paravirt.h:46 [inline]
flush_tlb_multi arch/x86/mm/tlb.c:1361 [inline]
flush_tlb_mm_range+0x45f/0x16f0 arch/x86/mm/tlb.c:1451
tlb_flush arch/x86/include/asm/tlb.h:23 [inline]
tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:509 [inline]
tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:499 [inline]
tlb_flush_mmu mm/mmu_gather.c:423 [inline]
tlb_finish_mmu+0x3fe/0x810 mm/mmu_gather.c:549
exit_mmap+0x454/0xa10 mm/mmap.c:1313
__mmput+0x12a/0x410 kernel/fork.c:1178
mmput+0x67/0x80 kernel/fork.c:1201
exit_mm kernel/exit.c:582 [inline]
do_exit+0x8b2/0x2af0 kernel/exit.c:964
do_group_exit+0xd5/0x2a0 kernel/exit.c:1119
get_signal+0x20ff/0x2210 kernel/signal.c:3037
arch_do_signal_or_restart+0x91/0x7e0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x8b/0x4f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x706/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7a9eb5d68e
Code: Unable to access opcode bytes at 0x7f7a9eb5d664.
RSP: 002b:00007fffdcda5708 EFLAGS: 00000246
ORIG_RAX: 00000000000000e6
RAX: 0000000000000000 RBX: 000055558fc36500 RCX: 00007f7a9eb5d68e
RDX: 00007fffdcda5760 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffdcda58b0
R13: 00007f7a9ee15fac R14: 000000000002bbe6 R15: 00007f7a9ee15fa0
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH 6.18 000/188] 6.18.32-rc1 review
From: Sasha Levin @ 2026-05-19 19:25 UTC (permalink / raw)
To: gregkh
Cc: Sasha Levin, achill, akpm, broonie, conor, f.fainelli, hargar,
jonathanh, linux-kernel, linux, lkft-triage, patches, patches,
pavel, rwarsow, shuah, sr, stable, sudipm.mukherjee, torvalds,
Miguel Ojeda, Jiri Kosina, Benjamin Tissoires, linux-input,
Johan Hovold, Nathan Chancellor
In-Reply-To: <20260516020430.110135-1-ojeda@kernel.org>
On Sat, May 16, 2026 at 04:04:30AM +0200, Miguel Ojeda wrote:
> Via arm32 I see:
>
> drivers/hid/hid-core.c:2050:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
> 2049 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
> | ~~~
> | %zu
> 2050 | report->id, csize, bsize);
> | ^~~~~
>
> It is also reproducible in mainline, though. Cc'ing a few folks...
Nathan's mainline fix (4d3a2a466b8d "HID: core: Fix size_t specifier in
hid_report_raw_event()") has been queued for 6.18.y and 7.0.y.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Alain Michaud @ 2026-05-19 18:46 UTC (permalink / raw)
To: Filipe Laíns; +Cc: jikos, bentiss, hadess, ogay, linux-input, linux-kernel
In-Reply-To: <64842eb18284bf49ab1e283b0fed1e6bdea7037d.camel@riseup.net>
On Tue, May 19, 2026 at 2:38 PM Filipe Laíns <lains@riseup.net> wrote:
>
> On Tue, 2026-05-12 at 13:22 +0000, Alain Michaud wrote:
> > Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
> > to the hidpp_devices matching table, enabling full HID++ support for
> > them.
> >
> > The added keyboards are:
> > - Logitech Signature K650 & B2B
> > - Logitech Pebble Keys 2 K380S
> > - Logitech Casa Pop-Up Desk & B2B
> > - Logitech Wave Keys & B2B
> > - Logitech Signature Slim K950 & B2B
> > - Logitech MX Keys S & B2B
> > - Logitech Keys-To-Go 2
> > - Logitech Pop Icon Keys
> > - Logitech MX Keys Mini & B2B
> > - Logitech Signature Slim Solar+ K980 B2B
> > - Logitech Bluetooth Keyboard K250/K251
> > - Logitech Signature Comfort K880 & B2B
>
> Hi Alain,
>
> Did you actually verify the functionality on each device, or did you just update
> the device ID list for new releases?
The later. Not all the functionality may be available across these
devices. However, these will definitely work with the Multi-Platform
feature patch currently under review.
>
> Cheers,
> Filipe Laíns
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Filipe Laíns @ 2026-05-19 18:38 UTC (permalink / raw)
To: Alain Michaud, jikos, bentiss; +Cc: hadess, ogay, linux-input, linux-kernel
In-Reply-To: <20260512132244.2194556-1-alainmichaud@google.com>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On Tue, 2026-05-12 at 13:22 +0000, Alain Michaud wrote:
> Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
> to the hidpp_devices matching table, enabling full HID++ support for
> them.
>
> The added keyboards are:
> - Logitech Signature K650 & B2B
> - Logitech Pebble Keys 2 K380S
> - Logitech Casa Pop-Up Desk & B2B
> - Logitech Wave Keys & B2B
> - Logitech Signature Slim K950 & B2B
> - Logitech MX Keys S & B2B
> - Logitech Keys-To-Go 2
> - Logitech Pop Icon Keys
> - Logitech MX Keys Mini & B2B
> - Logitech Signature Slim Solar+ K980 B2B
> - Logitech Bluetooth Keyboard K250/K251
> - Logitech Signature Comfort K880 & B2B
Hi Alain,
Did you actually verify the functionality on each device, or did you just update
the device ID list for new releases?
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Mismatched product ids for the ASUS ROG RAIKIRI PRO
From: Justin Opini @ 2026-05-19 17:37 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, torvalds
In-Reply-To: <Zjb8RrOFLHFSk_Gv@google.com>
Hey Dimity,
I had a question on the product id,
{ 0x0b05, 0x1abb, "ASUS ROG RAIKIRI PRO", 0, XTYPE_XBOXONE },
This doesn’t match both my devices so I was wondering if somehow we have similar named devices with need for different product ids or if there was a mistake in the original commit?
My relevant entries from lsusb are
Bus 001 Device 002: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
Bus 001 Device 003: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
On my system I have ended up using this udev rule for quite some time
ACTION=="add", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1a3c", GROUP="input", MODE="0660", TAG+="uaccess", TAG+="seat", RUN+="/bin/sh -c 'echo 0b05 1a3c > /sys/bus/usb/drivers/xpad/new_id'"
Regards,
Justin
^ permalink raw reply
* [PATCH v1] HID: i2c-hid-of: Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-19 16:04 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this patch is part of a bigger quest to use named initializers for
mainly struct i2c_device_id::driver_data to be able to modify
i2c_device_id. See e.g.
https://lore.kernel.org/all/20260518111203.639603-2-u.kleine-koenig@baylibre.com/
for the details.
This patch here isn't critical for this quest, as this driver doesn't
make use of .driver_data, so apart from the better readability this is
only about consistency with other subsystems.
This is the only i2c driver under drivers/hid, so this is the only patch
needed to adapt the whole subsystem to the new style for initializing
i2c_device_id arrays.
Best regards
Uwe
drivers/hid/i2c-hid/i2c-hid-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 57379b77e977..59393d71ddb9 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -144,8 +144,8 @@ MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
#endif
static const struct i2c_device_id i2c_hid_of_id_table[] = {
- { "hid" },
- { "hid-over-i2c" },
+ { .name = "hid" },
+ { .name = "hid-over-i2c" },
{ }
};
MODULE_DEVICE_TABLE(i2c, i2c_hid_of_id_table);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Benjamin Tissoires @ 2026-05-19 14:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Lee Jones, Jiri Kosina, Filipe Laíns, Bastien Nocera,
Ping Cheng, Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <2026051937-hefty-registry-37b2@gregkh>
On May 19 2026, Greg Kroah-Hartman wrote:
> On Tue, May 19, 2026 at 02:46:13PM +0200, Benjamin Tissoires wrote:
> > On May 19 2026, Lee Jones wrote:
> > > On Tue, 12 May 2026, Lee Jones wrote:
> > >
> > > > On Wed, 06 May 2026, Lee Jones wrote:
> > > >
> > > > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > > > >
> > > > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > > > bogus memset()") enforced the provided data to be at least the size of
> > > > > > the declared buffer in the report descriptor to prevent a buffer
> > > > > > overflow.
> > > > > >
> > > > > > We only had corner cases of malicious devices exposing the OOM because
> > > > > > in most cases, the buffer provided by the transport layer needs to be
> > > > > > allocated at probe time and is large enough to handle all the possible
> > > > > > reports.
> > > > > >
> > > > > > However, the patch from above, which enforces the spec a little bit more
> > > > > > introduced both regressions for devices not following the spec (not
> > > > > > necesserally malicious), but also a stream of errors for those devices.
> > > > > >
> > > > > > Let's revert to the old behavior by giving more information to HID core
> > > > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > > > to 0 and continue the processing.
> > > > > >
> > > > > > Note that the first commit makes an API change, but the callers are
> > > > > > relatively limited, so it should be fine on its own. The second patch
> > > > > > can't really make the same kind of API change because we have too many
> > > > > > callers in various subsystems. We can switch them one by one to the safe
> > > > > > approach when needed.
> > > > > >
> > > > > > The last 2 patches are small cleanups I initially put together with the
> > > > > > 2 first patches, but they can be applied on their own and don't need to
> > > > > > be pulled in stable like the first 2.
> > > > > >
> > > > > > Cheers,
> > > > > > Benjamin
> > > > > >
> > > > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > > > ---
> > > > > > Changes in v3:
> > > > > > - fixed ghib -> ghid in greybus
> > > > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > > > >
> > > > > > Changes in v2:
> > > > > > - added a small blurb explaining the difference between the safe and the
> > > > > > non safe version of hid_safe_input_report
> > > > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > > > >
> > > > > > ---
> > > > > > Benjamin Tissoires (4):
> > > > > > HID: pass the buffer size to hid_report_raw_event
> > > > > > HID: core: introduce hid_safe_input_report()
> > > > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > > > >
> > > > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > > > drivers/hid/hid-primax.c | 2 +-
> > > > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > > > drivers/staging/greybus/hid.c | 2 +-
> > > > > > include/linux/hid.h | 6 ++--
> > > > > > include/linux/hid_bpf.h | 14 +++++---
> > > > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > > > >
> > > > > What's the plan for this set Benjamin? -rcs or -next?
> > > >
> > > > Are there any updates on this set please?
> > > >
> > > > FYI, this set is still important to us.
> > > >
> > > > Ideally, if all is well, it would go into the -rcs for v7.1.
> > >
> > > I'm still actively tracking these.
> > >
> > > It looks like Mark has been reverting them from -next and I'm getting
> > > complaints from the Stable folks that they are causing build errors.
> > >
> > > drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> > > drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> > > 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
> > >
> > > Are you folks still working on this set?
> >
> > Well, everything is in Linus' tree:
> >
> > not yet in a released rc (taken yesterday by Linus directly):
> >
> > 4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
> >
> > Already in 7.1-rc4:
> >
> > 206342541fc8 HID: core: introduce hid_safe_input_report()
> > 2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
> >
> > Not sure why the patches don't apply to stable, but from an upstream
> > subsystem point of view, everything is in order.
>
> We dropped them from stable because of the build breakage :(
>
If that was just the i386 size_t issue, then it has been fixed in Linus'
tree. Could you try retaking them? Please?
Cheers,
Benjamin
^ permalink raw reply
* Re: [BUG] ALSA: usb-audio: use-after-free in snd_dualsense_ih_match during rapid USB reconnect
From: Takashi Iwai @ 2026-05-19 13:44 UTC (permalink / raw)
To: Sean Brar
Cc: linux-input, linux-sound, roderick.colenbrander, jikos, bentiss,
perex, tiwai
In-Reply-To: <909876aa-7498-4ca4-b3a6-6618fbc6209d@seanbrar.com>
On Mon, 11 May 2026 23:58:30 +0200,
Sean Brar wrote:
>
> A rapid USB disconnect/reconnect cycle on a DualSense controller
> (054c:0ce6) triggers a use-after-free in snd_dualsense_ih_match()
> (sound/usb/mixer_quirks.c), resulting in a general protection fault
> and leaving the USB subsystem in an unrecoverable state requiring a
> hard reboot.
>
> Kernel version: 7.0.5-arch1-1 (also reproduced the trigger on
> 7.0.3-arch1-2; affected code in sound/usb/mixer_quirks.c is
> unchanged on current mainline)
>
> Hardware:
> - Sony DualSense Wireless Controller (054c:0ce6, bcdDevice=1.00)
> - hw_version=0x00000711, fw_version=0x0110002a
> - Host: Gigabyte B550 AORUS PRO AC, BIOS F17 03/22/2024
>
> Trigger condition:
>
> When connected to a degraded USB port (intermittent electrical
> contact), the DualSense enters a rapid disconnect/reconnect cycle.
> snd_usb_audio times out (ETIMEDOUT, -110) querying mixer controls
> during probe, each timeout triggers a USB reset, and the device
> reconnects every 1–2 seconds. This is not a driver bug, it's the
> expected kernel behavior when USB communication is unreliable, but
> it creates a race window for the use-after-free described below.
>
> The bug:
>
> In sound/usb/mixer_quirks.c, snd_dualsense_ih_match() is invoked as
> an input handler match callback from input_register_device() during
> ps_probe() (hid_playstation). At line 575, it obtains a pointer to
> the USB device struct:
>
> snd_dev = mei->info.head.mixer->chip->dev;
>
> It then uses this pointer in dev_warn() calls at lines 579 and 585:
>
> dev_warn(&snd_dev->dev, "Failed to get input dev path\n");
> dev_warn(&snd_dev->dev, "Failed to get USB dev path\n");
>
> No reference is taken on snd_dev. If the USB device is concurrently
> disconnected and freed while snd_dualsense_ih_match() is executing,
> snd_dev becomes a dangling pointer. The dev_warn() call dereferences
> snd_dev->dev.kobj.name via dev_vprintk_emit() → strnlen(), faulting
> on the freed memory.
>
> The OOPS offset (snd_dualsense_ih_match.cold+0xf/0x2b) corresponds
> to the first dev_warn() at line 579. The compiler placed both error
> branches in a cold section, and the offset is consistent with the
> earlier branch.
>
> OOPS:
>
> Oops: general protection fault, probably for non-canonical address
> 0x441f0ffa1e0ff3: 0000 [#1] SMP NOPTI
> CPU: 14 UID: 0 PID: 108 Comm: kworker/14:0 Not tainted 7.0.5-arch1-1
> #1 PREEMPT(full)
> Hardware name: Gigabyte Technology Co., Ltd. B550 AORUS PRO AC/B550
> AORUS PRO AC, BIOS F17 03/22/2024
> Workqueue: usb_hub_wq hub_event
> RIP: 0010:strnlen+0x29/0x40
> RSP: 0018:ffffce3f40537378 EFLAGS: 00010202
> RAX: 00441f0ffa1e0ff3 RBX: 00441f0ffa1e0ff3 RCX: 0000000000000000
> RDX: 00441f0ffa1e1003 RSI: 0000000000000010 RDI: 00441f0ffa1e0ff3
> RBP: ffffce3f40537408 R08: 0000000000000000 R09: ffffce3f40537478
> R10: 0000000000000004 R11: ffffffffc20ebe12 R12: ffff8943511c80b0
> R13: ffff8943511c80b0 R14: ffff894345daf028 R15: ffffce3f40537418
> FS: 0000000000000000(0000) GS:ffff8962144e7000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055e7f9dc3c18 CR3: 0000000135ffe000 CR4: 0000000000f50ef0
>
> Stack trace:
>
> Call Trace:
> <TASK>
> dev_vprintk_emit+0x70/0x1b0
> dev_printk_emit+0x61/0x7b
> __dev_printk+0x2d/0x70
> _dev_warn+0x7f/0x99
> snd_dualsense_ih_match.cold+0xf/0x2b [snd_usb_audio
> a3e71fdbdb8c7ccfdfdb57dadc854b1d1e18445c]
> input_attach_handler.isra.0+0x4b/0xa0
> input_register_device.cold+0xf8/0x1f0
> ps_probe+0xf79/0x10dc [hid_playstation
> 0cc5feea5231aa914fe418c8a06b14588cd5f064]
> hid_device_probe+0x1b8/0x270
> hid_add_device+0xcd/0x130
> usbhid_probe+0x49b/0x6c0
> usb_probe_interface+0xf8/0x2f0
> usb_set_configuration+0x738/0x920
> usb_generic_driver_probe+0x4a/0x70
> usb_probe_device+0x44/0x170
> usb_new_device.cold+0x154/0x3fd
> hub_event+0x129d/0x1ad0
> process_one_work+0x19c/0x3a0
> worker_thread+0x1b1/0x310
> kthread+0xe1/0x120
> ret_from_fork+0x2bc/0x350
> ret_from_fork_asm+0x1a/0x30
> </TASK>
> ---[ end trace 0000000000000000 ]---
>
> Analysis:
>
> The race is between two concurrent paths:
>
> 1. Probe: hub_event → usb_new_device → ... → ps_probe →
> input_register_device → input_attach_handler →
> snd_dualsense_ih_match (accesses USB device struct at line 575)
>
> 2. Disconnect: hub_event → usb_disconnect → ... → USB device
> struct freed
>
> snd_dualsense_ih_match() retrieves snd_dev via the mixer→chip→dev
> chain at line 575 without taking a reference. A concurrent disconnect
> can free the USB device struct before the subsequent dev_warn() call
> dereferences it. The faulting RDI value (0x441f0ffa1e0ff3) is
> non-canonical and consistent with SLUB freed-object poisoning,
> confirming a use-after-free.
>
> Impact:
>
> After the OOPS, the USB subsystem is left in an unrecoverable state:
> all USB ports stop enumerating devices (including ports not involved
> in the reconnect cycle), and a clean shutdown hangs in USB driver
> teardown. A hard reset is required. The trigger condition (rapid USB
> reconnection due to a degraded port) is a normal hardware failure
> mode.
>
> Workaround:
>
> # /etc/modprobe.d/dualsense.conf
> options snd_usb_audio ignore_ctl_error=1
>
> This suppresses the mixer control timeouts that drive the reconnect
> cycle, preventing the race window from opening. DualSense headphone
> jack audio controls may not function correctly with this option.
>
> Steps to reproduce:
>
> Disconnect/reconnect loop (the trigger condition):
> 1. Load hid_playstation and snd_usb_audio (default on standard
> desktop kernels)
> 2. Connect a DualSense (054c:0ce6) via USB to a port with
> unreliable electrical contact
> 3. Observe rapid disconnect/reconnect in dmesg -w, with device
> number incrementing each cycle
>
> The OOPS:
> The OOPS was observed after the loop ran for several minutes. Exact
> timing-dependent reproduction beyond triggering the loop is not
> confirmed; this was observed once and not retested to avoid the
> unrecoverable USB hang.
>
> Kernel .config (7.0.5-arch1-1):
> https://gist.github.com/seanbrar/d97a577efc3f48098d300105c4de398b
> dmesg with OOPS (7.0.5-arch1-1):
> https://gist.github.com/seanbrar/994ed882ca6f25b93e4763a8906d0fd5
> dmesg with reconnect loop (7.0.3-arch1-2):
> https://gist.github.com/seanbrar/188a75bf69fffe0d089f7aa82c6aebb6
Thanks for the report.
As this is involved with two individual devices, I wonder the bug is
triggered at which timing -- has the sound interface been already
disconnected (or being disconnected) while the input is being probed?
In such a case, does the change below help?
Takashi
-- 8< --
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -705,14 +705,15 @@ static int snd_dualsense_resume_jack(struct usb_mixer_elem_list *list)
return 0;
}
-static void snd_dualsense_mixer_elem_free(struct snd_kcontrol *kctl)
+static void snd_dualsense_mixer_free(struct usb_mixer_interface *mixer)
{
- struct dualsense_mixer_elem_info *mei = snd_kcontrol_chip(kctl);
+ struct dualsense_mixer_elem_info *mei = mixer->private_data;
- if (mei->ih.event)
+ if (mei && mei->ih.event) {
input_unregister_handler(&mei->ih);
-
- snd_usb_mixer_elem_free(kctl);
+ mei->ih.event = NULL;
+ }
+ mixer->private_data = NULL;
}
static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
@@ -744,7 +745,7 @@ static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
}
strscpy(kctl->id.name, name, sizeof(kctl->id.name));
- kctl->private_free = snd_dualsense_mixer_elem_free;
+ kctl->private_free = snd_usb_mixer_elem_free;
err = snd_usb_mixer_add_control(&mei->info.head, kctl);
if (err)
@@ -774,6 +775,9 @@ static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
dev_warn(&mixer->chip->dev->dev,
"Could not register input handler: %d\n", err);
mei->ih.event = NULL;
+ } else {
+ mixer->private_free = snd_dualsense_mixer_free;
+ mixer->private_data = mei;
}
return 0;
^ permalink raw reply
* [RFC PATCH] HID: core: quiesce input in hid_hw_stop() to prevent use-after-free
From: Philipp Weber @ 2026-05-19 13:00 UTC (permalink / raw)
To: bentiss, jikos
Cc: eadavis, linux-input, linux-kernel, syzkaller-bugs,
syzbot+9eebf5f6544c5e873858
In-Reply-To: <69eed7e0.a00a0220.7773.0026.GAE@google.com>
A driver's probe calls hid_device_io_start() to enable input delivery,
then fails at a later initialization step and unwinds via hid_hw_stop().
The unwind frees struct hidraw via hidraw_disconnect() while in-flight
HID reports may still be running on another CPU, dereferencing the
freed object through hidraw_report_event(). syzbot reports the
resulting use-after-free for the corsair-psu HID driver.
Edward Adam Davis posted a per-driver fix for corsair-psu that adds
an explicit hid_device_io_stop() before hid_hw_stop() in the probe
error path ("hwmon: prevent packets from going to driver for probe",
2026-04-28). Auditing the tree shows 15 drivers call
hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:
drivers calling hid_device_io_start() without a matching
hid_device_io_stop() before hid_hw_stop():
drivers/hwmon/corsair-psu.c (fix posted by Edward)
drivers/hwmon/corsair-cpro.c
drivers/hwmon/nzxt-kraken3.c
drivers/hwmon/nzxt-smart2.c
drivers/hwmon/gigabyte_waterforce.c
drivers/hid/hid-logitech-dj.c
drivers/hid/hid-nintendo.c
drivers/hid/hid-mcp2221.c
Roughly half of all callers of the API are exposed. Centralize the
quiesce in hid_hw_stop() so callers do not have to remember the
matching stop: if a driver has left hdev->io_started true on entry,
call hid_device_io_stop() before hid_disconnect().
For the 7 drivers that already call hid_device_io_stop() correctly,
hdev->io_started is false on entry, the guard short-circuits, and
behavior is unchanged.
No Fixes: tag because the affected drivers gained their
hid_device_io_start() calls independently over years; the bug is a
class-wide API misuse rather than a regression from one commit.
Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858
Signed-off-by: Philipp Weber <kernel@phwe.de>
---
drivers/hid/hid-core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..6b024118d983 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2440,9 +2440,16 @@ EXPORT_SYMBOL_GPL(hid_hw_start);
*
* This is usually called from remove function or from probe when something
* failed and hid_hw_start was called already.
+ *
+ * If the caller enabled HID input via hid_device_io_start() and is unwinding
+ * without an explicit hid_device_io_stop(), quiesce input first so that
+ * in-flight reports cannot reach handlers (e.g. hidraw_report_event) whose
+ * backing objects hid_disconnect() is about to free.
*/
void hid_hw_stop(struct hid_device *hdev)
{
+ if (hdev->io_started)
+ hid_device_io_stop(hdev);
hid_disconnect(hdev);
hdev->ll_driver->stop(hdev);
}
base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Greg Kroah-Hartman @ 2026-05-19 12:48 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Lee Jones, Jiri Kosina, Filipe Laíns, Bastien Nocera,
Ping Cheng, Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <agxbD6k60vQYrJ6T@beelink>
On Tue, May 19, 2026 at 02:46:13PM +0200, Benjamin Tissoires wrote:
> On May 19 2026, Lee Jones wrote:
> > On Tue, 12 May 2026, Lee Jones wrote:
> >
> > > On Wed, 06 May 2026, Lee Jones wrote:
> > >
> > > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > > >
> > > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > > bogus memset()") enforced the provided data to be at least the size of
> > > > > the declared buffer in the report descriptor to prevent a buffer
> > > > > overflow.
> > > > >
> > > > > We only had corner cases of malicious devices exposing the OOM because
> > > > > in most cases, the buffer provided by the transport layer needs to be
> > > > > allocated at probe time and is large enough to handle all the possible
> > > > > reports.
> > > > >
> > > > > However, the patch from above, which enforces the spec a little bit more
> > > > > introduced both regressions for devices not following the spec (not
> > > > > necesserally malicious), but also a stream of errors for those devices.
> > > > >
> > > > > Let's revert to the old behavior by giving more information to HID core
> > > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > > to 0 and continue the processing.
> > > > >
> > > > > Note that the first commit makes an API change, but the callers are
> > > > > relatively limited, so it should be fine on its own. The second patch
> > > > > can't really make the same kind of API change because we have too many
> > > > > callers in various subsystems. We can switch them one by one to the safe
> > > > > approach when needed.
> > > > >
> > > > > The last 2 patches are small cleanups I initially put together with the
> > > > > 2 first patches, but they can be applied on their own and don't need to
> > > > > be pulled in stable like the first 2.
> > > > >
> > > > > Cheers,
> > > > > Benjamin
> > > > >
> > > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > > ---
> > > > > Changes in v3:
> > > > > - fixed ghib -> ghid in greybus
> > > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > > >
> > > > > Changes in v2:
> > > > > - added a small blurb explaining the difference between the safe and the
> > > > > non safe version of hid_safe_input_report
> > > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > > >
> > > > > ---
> > > > > Benjamin Tissoires (4):
> > > > > HID: pass the buffer size to hid_report_raw_event
> > > > > HID: core: introduce hid_safe_input_report()
> > > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > > >
> > > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > > drivers/hid/hid-primax.c | 2 +-
> > > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > > drivers/staging/greybus/hid.c | 2 +-
> > > > > include/linux/hid.h | 6 ++--
> > > > > include/linux/hid_bpf.h | 14 +++++---
> > > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > > >
> > > > What's the plan for this set Benjamin? -rcs or -next?
> > >
> > > Are there any updates on this set please?
> > >
> > > FYI, this set is still important to us.
> > >
> > > Ideally, if all is well, it would go into the -rcs for v7.1.
> >
> > I'm still actively tracking these.
> >
> > It looks like Mark has been reverting them from -next and I'm getting
> > complaints from the Stable folks that they are causing build errors.
> >
> > drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> > drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> > 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
> >
> > Are you folks still working on this set?
>
> Well, everything is in Linus' tree:
>
> not yet in a released rc (taken yesterday by Linus directly):
>
> 4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
>
> Already in 7.1-rc4:
>
> 206342541fc8 HID: core: introduce hid_safe_input_report()
> 2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
>
> Not sure why the patches don't apply to stable, but from an upstream
> subsystem point of view, everything is in order.
We dropped them from stable because of the build breakage :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Benjamin Tissoires @ 2026-05-19 12:46 UTC (permalink / raw)
To: Lee Jones
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260519111723.GU305027@google.com>
On May 19 2026, Lee Jones wrote:
> On Tue, 12 May 2026, Lee Jones wrote:
>
> > On Wed, 06 May 2026, Lee Jones wrote:
> >
> > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > >
> > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > bogus memset()") enforced the provided data to be at least the size of
> > > > the declared buffer in the report descriptor to prevent a buffer
> > > > overflow.
> > > >
> > > > We only had corner cases of malicious devices exposing the OOM because
> > > > in most cases, the buffer provided by the transport layer needs to be
> > > > allocated at probe time and is large enough to handle all the possible
> > > > reports.
> > > >
> > > > However, the patch from above, which enforces the spec a little bit more
> > > > introduced both regressions for devices not following the spec (not
> > > > necesserally malicious), but also a stream of errors for those devices.
> > > >
> > > > Let's revert to the old behavior by giving more information to HID core
> > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > to 0 and continue the processing.
> > > >
> > > > Note that the first commit makes an API change, but the callers are
> > > > relatively limited, so it should be fine on its own. The second patch
> > > > can't really make the same kind of API change because we have too many
> > > > callers in various subsystems. We can switch them one by one to the safe
> > > > approach when needed.
> > > >
> > > > The last 2 patches are small cleanups I initially put together with the
> > > > 2 first patches, but they can be applied on their own and don't need to
> > > > be pulled in stable like the first 2.
> > > >
> > > > Cheers,
> > > > Benjamin
> > > >
> > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > ---
> > > > Changes in v3:
> > > > - fixed ghib -> ghid in greybus
> > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > >
> > > > Changes in v2:
> > > > - added a small blurb explaining the difference between the safe and the
> > > > non safe version of hid_safe_input_report
> > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > >
> > > > ---
> > > > Benjamin Tissoires (4):
> > > > HID: pass the buffer size to hid_report_raw_event
> > > > HID: core: introduce hid_safe_input_report()
> > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > >
> > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > drivers/hid/hid-primax.c | 2 +-
> > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > drivers/staging/greybus/hid.c | 2 +-
> > > > include/linux/hid.h | 6 ++--
> > > > include/linux/hid_bpf.h | 14 +++++---
> > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > >
> > > What's the plan for this set Benjamin? -rcs or -next?
> >
> > Are there any updates on this set please?
> >
> > FYI, this set is still important to us.
> >
> > Ideally, if all is well, it would go into the -rcs for v7.1.
>
> I'm still actively tracking these.
>
> It looks like Mark has been reverting them from -next and I'm getting
> complaints from the Stable folks that they are causing build errors.
>
> drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
>
> Are you folks still working on this set?
Well, everything is in Linus' tree:
not yet in a released rc (taken yesterday by Linus directly):
4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
Already in 7.1-rc4:
206342541fc8 HID: core: introduce hid_safe_input_report()
2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
Not sure why the patches don't apply to stable, but from an upstream
subsystem point of view, everything is in order.
I still have to resend the last 2 patches, but they are not fixing
anything, just nice to have.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Lee Jones @ 2026-05-19 11:17 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260512101723.GU305027@google.com>
On Tue, 12 May 2026, Lee Jones wrote:
> On Wed, 06 May 2026, Lee Jones wrote:
>
> > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> >
> > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > bogus memset()") enforced the provided data to be at least the size of
> > > the declared buffer in the report descriptor to prevent a buffer
> > > overflow.
> > >
> > > We only had corner cases of malicious devices exposing the OOM because
> > > in most cases, the buffer provided by the transport layer needs to be
> > > allocated at probe time and is large enough to handle all the possible
> > > reports.
> > >
> > > However, the patch from above, which enforces the spec a little bit more
> > > introduced both regressions for devices not following the spec (not
> > > necesserally malicious), but also a stream of errors for those devices.
> > >
> > > Let's revert to the old behavior by giving more information to HID core
> > > to be able to decide whether it can or not memset the rest of the buffer
> > > to 0 and continue the processing.
> > >
> > > Note that the first commit makes an API change, but the callers are
> > > relatively limited, so it should be fine on its own. The second patch
> > > can't really make the same kind of API change because we have too many
> > > callers in various subsystems. We can switch them one by one to the safe
> > > approach when needed.
> > >
> > > The last 2 patches are small cleanups I initially put together with the
> > > 2 first patches, but they can be applied on their own and don't need to
> > > be pulled in stable like the first 2.
> > >
> > > Cheers,
> > > Benjamin
> > >
> > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > ---
> > > Changes in v3:
> > > - fixed ghib -> ghid in greybus
> > > - fixed i386 size_t debug size reported by kernel-bot
> > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > >
> > > Changes in v2:
> > > - added a small blurb explaining the difference between the safe and the
> > > non safe version of hid_safe_input_report
> > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > >
> > > ---
> > > Benjamin Tissoires (4):
> > > HID: pass the buffer size to hid_report_raw_event
> > > HID: core: introduce hid_safe_input_report()
> > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > >
> > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > drivers/hid/hid-gfrm.c | 4 +--
> > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > drivers/hid/hid-primax.c | 2 +-
> > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > drivers/staging/greybus/hid.c | 2 +-
> > > include/linux/hid.h | 6 ++--
> > > include/linux/hid_bpf.h | 14 +++++---
> > > 13 files changed, 109 insertions(+), 78 deletions(-)
> >
> > What's the plan for this set Benjamin? -rcs or -next?
>
> Are there any updates on this set please?
>
> FYI, this set is still important to us.
>
> Ideally, if all is well, it would go into the -rcs for v7.1.
I'm still actively tracking these.
It looks like Mark has been reverting them from -next and I'm getting
complaints from the Stable folks that they are causing build errors.
drivers/hid/hid-core.c: In function 'hid_safe_input_report':
drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
Are you folks still working on this set?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Lee Jones @ 2026-05-19 11:13 UTC (permalink / raw)
To: Ping Cheng
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, stable
In-Reply-To: <CAF8JNhKTMpT3CGq_oDqaGVygqXK0jjvrvjxbAWUerqtWzdB9+Q@mail.gmail.com>
On Wed, 13 May 2026, Ping Cheng wrote:
> On Wed, May 13, 2026 at 1:05 AM Lee Jones <lee@kernel.org> wrote:
> >
> > wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
> > usage is always located in the first field (field[0]) of the feature report.
> > However, a device can specify HID_DG_INPUTMODE in a different field.
> >
> > If HID_DG_INPUTMODE is in a field other than the first one and the first
> > field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
> > this leads to an out-of-bounds write to r->field[0]->value.
> >
> > Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
> > hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
> > this stored field index to access the correct field and add bounds
> > checks to ensure both the field index and the value index are within
> > valid ranges before writing.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
> > Signed-off-by: Lee Jones <lee@kernel.org>
>
> Patch looks sensible to me. Thank you for your effort, Lee!
>
> Tested-by: Ping Cheng <ping.cheng@wacom.com>
> Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Thank you Ping, I appreciate your review.
HID folks - any movement on this please?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] i2c: add sanity check for input SMBus data length
From: Wolfram Sang @ 2026-05-19 9:43 UTC (permalink / raw)
To: Edward Adam Davis
Cc: syzbot+64ca69977b37604cd6d9, bentiss, jikos, linux-i2c,
linux-input, linux-kernel, michael.zaidman, syzkaller-bugs
In-Reply-To: <tencent_9443A8C45A37693763A6D7D3658367896405@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
Hi,
thanks for your patch!
On Tue, Jan 20, 2026 at 09:47:02PM +0800, Edward Adam Davis wrote:
> The value passed to block[0] in the user-constructed data is too large,
> exceeding the length that data for SMBus messages can accommodate. This
> triggered the out-of-bounds access reported by syzbot [1].
>
> Adding relevant data size checks in the smbus ioctl can prevent this
> out-of-bounds access.
>
> [1]
> BUG: KASAN: stack-out-of-bounds in ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
> Read of size 42 at addr ffffc90003427d81 by task syz.2.65/6119
> Call Trace:
> ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
> ft260_smbus_xfer+0x22c/0x640 drivers/hid/hid-ft260.c:736
>
Did you look for a suitable Fixes tag?
> Reported-by: syzbot+64ca69977b37604cd6d9@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> drivers/i2c/i2c-dev.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
> index e9577f920286..6725a49d6921 100644
> --- a/drivers/i2c/i2c-dev.c
> +++ b/drivers/i2c/i2c-dev.c
> @@ -378,6 +378,14 @@ static noinline int i2cdev_ioctl_smbus(struct i2c_client *client,
> (read_write == I2C_SMBUS_WRITE)) {
> if (copy_from_user(&temp, data, datasize))
> return -EFAULT;
> +
> + if (temp.block[0] > datasize) {
> + dev_dbg(&client->adapter->dev,
> + "user input data size (%u) is too big "
> + "in ioctl I2C_SMBUS.\n",
Strings stay in one line, please, even if they break the line length.
> + temp.block[0]);
> + return -EINVAL;
> + }
> }
> if (size == I2C_SMBUS_I2C_BLOCK_BROKEN) {
> /* Convert old I2C block commands to the new
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: move Risc PC-specific <asm/hardware/iomd.h> header into mach-rpc
From: Helge Deller @ 2026-05-19 6:51 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-arm-kernel, linux-i2c, linux-input,
linux-fbdev
Cc: Russell King, Andi Shyti, Dmitry Torokhov, Kees Cook
In-Reply-To: <20260510031100.255248-1-enelsonmoore@gmail.com>
On 5/10/26 05:10, Ethan Nelson-Moore wrote:
> The <asm/hardware/iomd.h> header is specific to the IOMD chip used on
> the Risc PC. Move it into mach-rpc to avoid polluting asm/hardware/
> with machine-specific headers.
>
> Also take the opportunity to remove a comment with the file path from
> the header, which is bad style.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> MAINTAINERS | 1 -
> arch/arm/mach-rpc/dma.c | 2 +-
> arch/arm/{include/asm/hardware => mach-rpc/include/mach}/iomd.h | 2 --
> arch/arm/mach-rpc/irq.c | 2 +-
> arch/arm/mach-rpc/riscpc.c | 2 +-
> arch/arm/mach-rpc/time.c | 2 +-
> drivers/i2c/busses/i2c-acorn.c | 2 +-
> drivers/input/mouse/rpcmouse.c | 2 +-
> drivers/input/serio/rpckbd.c | 2 +-
> drivers/video/fbdev/acornfb.h | 2 +-
Regarding the fbdev change:
Acked-by: Helge Deller <deller@gmx.de>
I assume this patch is pushed via the arm tree?
Helge
^ permalink raw reply
* RE: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup and cleanup
From: Zhang, Lixu @ 2026-05-19 5:22 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos@kernel.org, jic23@kernel.org,
srinivas.pandruvada@linux.intel.com, Lechner, David,
nuno.sa@analog.com, andy@kernel.org, sakari.ailus@linux.intel.com,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <agoi55wCo//eY1YQ@hu-ckantibh-hyd.qualcomm.com>
>-----Original Message-----
>From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>Sent: Monday, May 18, 2026 4:20 AM
>To: Zhang, Lixu <lixu.zhang@intel.com>
>Cc: jikos@kernel.org; jic23@kernel.org; srinivas.pandruvada@linux.intel.com;
>Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>andy@kernel.org; sakari.ailus@linux.intel.com; linux-input@vger.kernel.org;
>linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup and
>cleanup
>
>On Thu, May 14, 2026 at 02:47:52AM +0000, Zhang, Lixu wrote:
>> Tested-by: Zhang Lixu <lixu.zhang@intel.com>
>
>Hi Zhang,
>
>Thanks for the testing and validaiton.
>I hope you validated the complete series, including the unbind flow for the
>drivers using devm API.
Hi Sanjay,
Yes, I validated the complete series. The unbind flow was tested as Srinivas previously
suggested - performing the unbind while iio-sensor-proxy has an open session. No
regression issues were observed.
Since iio-sensor-proxy does not typically open a gyro session, I applied the same changes
from hid-sensor-gyro-3d to hid-sensor-accel-3d and tested the unbind flow on that driver
as well. Again, no regression issues were found.
Thanks,
Lixu
>
>Hi Jonathan,
>
>How should we take this series forward? should I extend the series to cover
>remaining HID IIO drivers for this devm API, or this series can applied to IIO tree
>first and sent followup patches on top of that?
>
>Thanks, Sanjay
>
>>
>> >-----Original Message-----
>> >From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >Sent: Saturday, May 9, 2026 6:11 PM
>> >To: jikos@kernel.org; jic23@kernel.org;
>> >srinivas.pandruvada@linux.intel.com
>> >Cc: Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>> >andy@kernel.org; sanjayembeddedse@gmail.com;
>> >sakari.ailus@linux.intel.com; linux-input@vger.kernel.org; linux-
>> >iio@vger.kernel.org; linux-kernel@vger.kernel.org
>> >Subject: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup
>> >and cleanup
>> >
>> >From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >
>> >Key highlights:
>> >- Prepare change as pre-requisite for devm conversion for HID IIO
>> > drivers by removing redundant argument
>> >- Add devm API to setup trigger and clenaup resource using
>> > devm_add_action_or_reset()
>> >- few cleanup and prepratory changes before updating driver for devm_
>> >- few sample driver update using devm conversion to auto release
>> >resource
>> >
>> >changes in v3:
>> >- Added cleanup and prepratory changes before adding devm_ API
>> > conversion based on self review: 0002, 0004, 0006, 0007 and 0008
>> >- Address andy's review comment on commit message and coding style
>> >- v2 series -> https://lore.kernel.org/all/20260429175918.2541914-1-
>> >sanjayembedded@gmail.com/
>> >changes in v2:
>> >- Following input from Jonathan and Andy, squash initial patch v1
>> > series in single change as individual change should not break
>> >anything
>> >- Add devm API support and two driver using the same
>> >- v1 series -> https://lore.kernel.org/all/20260428071613.1134053-1-
>> >sanjayembedded@gmail.com/
>> >
>> >Testing:
>> > - Compiled with W=1
>> > - Build-tested on QEMU x86_64
>> >
>> >Based on further feedback and reviews, I would extend this series to
>> >convert all HID IIO driver to use devm_* API.
>> >
>> >Thanks,
>> >Sanjay Chitroda
>> >
>> >
>> >Sanjay Chitroda (9):
>> > iio: hid-sensors: drop redundant iio_dev argument
>> > iio: hid-sensors: cleanup codestyle warning
>> > iio: hid-sensors: introduce device managed API
>> > iio: gyro: hid-sensor-gyro-3d: cleanup codestyle warning
>> > iio: gyro: hid-sensor-gyro-3d: drop hid_sensor_remove_trigger() using
>> > devm API
>> > iio: humidity: hid-sensor-humidity: cleanup codestyle check
>> > iio: humidity: hid-sensor-humidity: use common device for devres
>> > iio: humidity: hid-sensor-humidity: use local struct device
>> > iio: humidity: hid-sensor-humidity: drop hid_sensor_remove_trigger()
>> > using devm API
>> >
>> > drivers/iio/accel/hid-sensor-accel-3d.c | 4 +-
>> > .../common/hid-sensors/hid-sensor-trigger.c | 24 +++++++-
>> > .../common/hid-sensors/hid-sensor-trigger.h | 5 +-
>> > drivers/iio/gyro/hid-sensor-gyro-3d.c | 16 ++---
>> > drivers/iio/humidity/hid-sensor-humidity.c | 61 +++++++++----------
>> > drivers/iio/light/hid-sensor-als.c | 4 +-
>> > drivers/iio/light/hid-sensor-prox.c | 4 +-
>> > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 4 +-
>> >drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +-
>> >drivers/iio/orientation/hid- sensor-rotation.c | 4 +- .../position/hid-sensor-
>custom-intel-hinge.c | 4 +-
>> > drivers/iio/pressure/hid-sensor-press.c | 4 +-
>> > .../iio/temperature/hid-sensor-temperature.c | 4 +-
>> > 13 files changed, 78 insertions(+), 64 deletions(-)
>> >
>> >
>> >base-commit: 39b80c5c9830d12d2d6531059001301c4265322a
>> >--
>> >2.34.1
>> >
>>
^ permalink raw reply
* Re: [PATCH v6 4/4] HID: hid-msi: Add Rumble Intensity Attributes
From: sashiko-bot @ 2026-05-19 0:22 UTC (permalink / raw)
To: Derek J. Clark; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260518222935.1802071-5-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] State machine desynchronization and data race on `profile_pending` leads to corrupted rumble intensity reads.
--
commit 85612b755f6822082f71e029c33a01200dc4046f
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi: Add Rumble Intensity Attributes
Adds intensity adjustment for the left and right rumble motors.
> diff --git a/drivers/hid/hid-msi.c b/drivers/hid/hid-msi.c
> index 4d267b896da72..339f256b60dbe 100644
> --- a/drivers/hid/hid-msi.c
> +++ b/drivers/hid/hid-msi.c
[ ... ]
> @@ -882,6 +901,142 @@ static ssize_t button_mapping_options_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(button_mapping_options);
[ ... ]
> +static ssize_t rumble_intensity_left_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + u8 data[4] = { 0x01, (rumble_addr[0] >> 8) & 0xff, rumble_addr[0] & 0xff, 0x01 };
> + struct hid_device *hdev = to_hid_device(dev);
> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
> + int ret;
> + u8 val;
> +
> + if (!drvdata->gamepad_registered)
> + return -ENODEV;
> +
> + guard(mutex)(&drvdata->profile_mutex);
> + drvdata->profile_pending = CLAW_RUMBLE_LEFT_PENDING;
> + ret = claw_hw_output_report(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data,
> + ARRAY_SIZE(data), 25);
> + if (ret) {
> + drvdata->profile_pending = CLAW_NO_PENDING;
> + return ret;
> + }
Can the profile_pending state become desynchronized if a hardware read times
out?
If claw_hw_output_report() times out, it sets
drvdata->profile_pending = CLAW_NO_PENDING and returns.
If a subsequent call to rumble_intensity_right_show() sets
drvdata->profile_pending = CLAW_RUMBLE_RIGHT_PENDING, and then the delayed
hardware ACK from the first left request arrives, claw_profile_event() will
misattribute the response.
It will read the left motor's intensity into drvdata->rumble_intensity_right,
corrupting the state:
case CLAW_RUMBLE_RIGHT_PENDING:
scoped_guard(spinlock_irqsave, &drvdata->rumble_lock)
drvdata->rumble_intensity_right = cmd_rep->data[4];
Additionally, claw_profile_event() clears
drvdata->profile_pending = CLAW_NO_PENDING locklessly at the end, which
could race with other process contexts accessing it under profile_mutex.
Should claw_profile_event() validate the memory address in the response payload
to ensure it belongs to the pending request, and synchronize accesses to
profile_pending?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518222935.1802071-1-derekjohn.clark@gmail.com?part=4
^ permalink raw reply
* [PATCH v3] platform/x86/lenovo: Add Yoga Book 9 keyboard dock detection driver
From: Dave Carey @ 2026-05-19 0:02 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: pithenrich2d, mpearson-lenovo, derekjohn.clark, W_Armin,
platform-driver-x86, linux-input, linux-kernel, dmitry.torokhov,
Dave Carey
In-Reply-To: <20260517150224.50191-1-carvsdriver@gmail.com>
The Lenovo Yoga Book 9 14IAH10 ships with a detachable Bluetooth keyboard
that magnetically attaches to the bottom (secondary) screen in one of two
positions. The Embedded Controller tracks the attachment state in a 2-bit
field called BKBD and signals changes via WMI event GUID
806BD2A2-177B-481D-BFB5-3BA0BB4A2285 (notify ID 0xEB on the WM10 ACPI
device).
The current BKBD state is read via a separate WMI query GUID
E7F300FA-21CD-4003-ADAC-2696135982E6 (WQAF method), which returns an
8-byte buffer: bytes [0..3] hold the LFID constant 0x00060000 and bytes
[4..7] hold the BKBD value.
BKBD encoding:
0 = keyboard detached
1 = keyboard docked on top half of bottom screen
2 = keyboard docked on bottom half of bottom screen
3 = reserved (not observed in practice)
Both GUIDs are children of the same ACPI device (WM10), so both are
matched by a single WMI driver. The query device pointer is stored in a
module-level variable protected by a mutex; the event device uses
wmidev_block_query() via the stored pointer rather than the deprecated
global wmi_query_block(). get_device()/put_device() bracket each use of
the stored pointer so probe/remove races cannot produce a use-after-free.
This driver:
- Registers as a WMI driver on both the event and query GUIDs.
- Queries BKBD state synchronously on probe and on each WMI
notification.
- Sets the initial SW_TABLET_MODE bit before input_register_device()
via __set_bit() so userspace always reads the correct state on first
open.
- Reports SW_TABLET_MODE=1 when detached, SW_TABLET_MODE=0 when docked
in either position (a physical keyboard is present in both cases).
- Exposes the raw BKBD value via a read-only sysfs attribute
"keyboard_position" for use by userspace (e.g. to distinguish between
the two docked positions for different UI layouts). The attribute is
registered per-device via devm_device_add_groups() in the event-device
probe path only; the query device has no priv and no sysfs groups.
Tested on: Lenovo Yoga Book 9 14IAH10 (model 83KJ), kernel 6.19.
Signed-off-by: Dave Carey <carvsdriver@gmail.com>
---
.../testing/sysfs-driver-lenovo-yb9-kbdock | 21 ++
MAINTAINERS | 6 +
drivers/platform/x86/lenovo/Kconfig | 14 ++
drivers/platform/x86/lenovo/Makefile | 1 +
drivers/platform/x86/lenovo/yb9-kbdock.c | 270 ++++++++++++++++++
5 files changed, 312 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
create mode 100644 MAINTAINERS
create mode 100644 drivers/platform/x86/lenovo/yb9-kbdock.c
diff --git a/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock b/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
new file mode 100644
index 0000000..bb57690
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
@@ -0,0 +1,21 @@
+What: /sys/bus/wmi/drivers/lenovo-yb9-kbdock/<guid>/keyboard_position
+Date: April 2026
+KernelVersion: 6.10
+Contact: Dave Carey <carvsdriver@gmail.com>
+Description:
+ Read-only attribute reporting the current keyboard dock position
+ as reported by the Embedded Controller on the Lenovo Yoga Book 9
+ 14IAH10.
+
+ Possible values:
+
+ == ============================================================
+ 0 detached — keyboard is not docked to any screen
+ 1 top-half — keyboard docked on the top half of the bottom screen
+ 2 bottom-half — keyboard docked on the bottom half of the bottom screen
+ == ============================================================
+
+ The value is formatted as "<n> (<name>)\n", e.g. "1 (top-half)\n".
+
+ SW_TABLET_MODE input events are also emitted: 0 when the keyboard
+ is docked (either position), 1 when detached.
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000..cb765b4
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,6 @@
+LENOVO YOGA BOOK 9 KEYBOARD DOCK DRIVER
+M: Dave Carey <carvsdriver@gmail.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
+F: drivers/platform/x86/lenovo/yb9-kbdock.c
diff --git a/drivers/platform/x86/lenovo/Kconfig b/drivers/platform/x86/lenovo/Kconfig
index 9c48487..938b361 100644
--- a/drivers/platform/x86/lenovo/Kconfig
+++ b/drivers/platform/x86/lenovo/Kconfig
@@ -43,6 +43,20 @@ config LENOVO_WMI_CAMERA
To compile this driver as a module, choose M here: the module
will be called lenovo-wmi-camera.
+config LENOVO_YB9_KBDOCK
+ tristate "Lenovo Yoga Book 9 keyboard dock detection"
+ depends on ACPI_WMI
+ depends on DMI
+ depends on INPUT
+ help
+ Say Y here to enable keyboard dock detection on the Lenovo Yoga Book 9
+ 14IAH10. The detachable Bluetooth keyboard magnetically attaches to
+ either screen; this driver reports SW_TABLET_MODE input events based
+ on the attachment state and exposes the raw position in sysfs.
+
+ To compile this driver as a module, choose M here: the module will be
+ called lenovo-yb9-kbdock.
+
config LENOVO_YMC
tristate "Lenovo Yoga Tablet Mode Control"
depends on ACPI_WMI
diff --git a/drivers/platform/x86/lenovo/Makefile b/drivers/platform/x86/lenovo/Makefile
index 7b2128e..2842d7d 100644
--- a/drivers/platform/x86/lenovo/Makefile
+++ b/drivers/platform/x86/lenovo/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_THINKPAD_LMI) += think-lmi.o
obj-$(CONFIG_THINKPAD_ACPI) += thinkpad_acpi.o
lenovo-target-$(CONFIG_LENOVO_WMI_HOTKEY_UTILITIES) += wmi-hotkey-utilities.o
+lenovo-target-$(CONFIG_LENOVO_YB9_KBDOCK) += yb9-kbdock.o
lenovo-target-$(CONFIG_LENOVO_YMC) += ymc.o
lenovo-target-$(CONFIG_YOGABOOK) += yogabook.o
lenovo-target-$(CONFIG_YT2_1380) += yoga-tab2-pro-1380-fastcharger.o
diff --git a/drivers/platform/x86/lenovo/yb9-kbdock.c b/drivers/platform/x86/lenovo/yb9-kbdock.c
new file mode 100644
index 0000000..0000000
--- /dev/null
+++ b/drivers/platform/x86/lenovo/yb9-kbdock.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Lenovo Yoga Book 9 keyboard-dock detection
+ *
+ * Reports SW_TABLET_MODE based on keyboard attachment state and exposes the
+ * raw dock position via sysfs.
+ *
+ * Copyright (C) 2026 Dave Carey <carvsdriver@gmail.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/acpi.h>
+#include <linux/bitfield.h>
+#include <linux/cleanup.h>
+#include <linux/dmi.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/wmi.h>
+
+/*
+ * WM10 ACPI device (_UID "GMZN") exposes two relevant WMI GUIDs:
+ * YB9_KBDOCK_EVENT_GUID — notify ID 0xEB fires on attachment state change.
+ * YB9_KBDOCK_QUERY_GUID — object "AF" (WQAF), returns an 8-byte buffer
+ * whose upper four bytes hold the BKBD value.
+ *
+ * BKBD encoding:
+ * 0 (BKBD_DETACHED) — keyboard detached → SW_TABLET_MODE = 1
+ * 1 (BKBD_TOP_HALF) — docked, top half → SW_TABLET_MODE = 0
+ * 2 (BKBD_BOTTOM_HALF) — docked, bottom half → SW_TABLET_MODE = 0
+ * 3 — reserved; treated as an error
+ */
+#define YB9_KBDOCK_EVENT_GUID "806BD2A2-177B-481D-BFB5-3BA0BB4A2285"
+#define YB9_KBDOCK_QUERY_GUID "E7F300FA-21CD-4003-ADAC-2696135982E6"
+#define YB9_KBDOCK_QUERY_INSTANCE 0
+
+#define BKBD_DETACHED 0
+#define BKBD_TOP_HALF 1
+#define BKBD_BOTTOM_HALF 2
+#define BKBD_MASK GENMASK(1, 0)
+
+/* Distinguish the two GUIDs via the id_table context field. */
+enum yb9_guid_type { YB9_GUID_EVENT, YB9_GUID_QUERY };
+
+/*
+ * Both GUIDs are children of the same ACPI device (WM10). Store the query
+ * WMI device globally so the event-device probe and notify path can reach it
+ * via wmidev_block_query(). Protected by yb9_query_lock during probe/remove.
+ */
+static struct wmi_device *yb9_query_wdev;
+static DEFINE_MUTEX(yb9_query_lock);
+
+struct yb9_kbdock_priv {
+ struct input_dev *input_dev;
+ unsigned int bkbd;
+};
+
+/* Returns 0–2 on success, -errno on error. */
+static int yb9_kbdock_query(struct wmi_device *event_wdev,
+ struct wmi_device *query_wdev)
+{
+ u32 bkbd;
+
+ union acpi_object *obj __free(kfree) =
+ wmidev_block_query(query_wdev, YB9_KBDOCK_QUERY_INSTANCE);
+ if (!obj) {
+ dev_warn(&event_wdev->dev, "WQAF query returned NULL\n");
+ return -EIO;
+ }
+
+ /*
+ * WQAF returns an 8-byte buffer: bytes [0..3] = LFID (0x00060000),
+ * bytes [4..7] = BKBD value. Guard against short buffers.
+ */
+ if (obj->type == ACPI_TYPE_BUFFER && obj->buffer.length >= 8)
+ memcpy(&bkbd, obj->buffer.pointer + 4, sizeof(bkbd));
+ else if (obj->type == ACPI_TYPE_INTEGER)
+ bkbd = obj->integer.value;
+ else {
+ dev_warn(&event_wdev->dev,
+ "WQAF: unexpected result type %d len %u\n",
+ obj->type, obj->type == ACPI_TYPE_BUFFER ? obj->buffer.length : 0);
+ return -EIO;
+ }
+
+ bkbd = FIELD_GET(BKBD_MASK, bkbd);
+ if (bkbd == 3) {
+ dev_warn(&event_wdev->dev, "BKBD value 3 is reserved\n");
+ return -EINVAL;
+ }
+
+ return bkbd;
+}
+
+static void yb9_kbdock_update(struct wmi_device *wdev)
+{
+ struct yb9_kbdock_priv *priv = dev_get_drvdata(&wdev->dev);
+ struct wmi_device *qwdev;
+ int tablet_mode;
+ int bkbd;
+
+ mutex_lock(&yb9_query_lock);
+ qwdev = yb9_query_wdev;
+ if (qwdev)
+ get_device(&qwdev->dev);
+ mutex_unlock(&yb9_query_lock);
+ if (!qwdev)
+ return;
+
+ bkbd = yb9_kbdock_query(wdev, qwdev);
+ put_device(&qwdev->dev);
+ if (bkbd < 0)
+ return;
+
+ priv->bkbd = bkbd;
+ tablet_mode = (bkbd == BKBD_DETACHED) ? 1 : 0;
+
+ input_report_switch(priv->input_dev, SW_TABLET_MODE, tablet_mode);
+ input_sync(priv->input_dev);
+
+ dev_dbg(&wdev->dev, "BKBD=%u tablet_mode=%d\n", bkbd, tablet_mode);
+}
+
+static void yb9_kbdock_notify(struct wmi_device *wdev, union acpi_object *data)
+{
+ yb9_kbdock_update(wdev);
+}
+
+static ssize_t keyboard_position_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ static const char * const names[] = {
+ "detached", "top-half", "bottom-half",
+ };
+ struct yb9_kbdock_priv *priv = dev_get_drvdata(dev);
+ unsigned int bkbd = priv->bkbd;
+
+ if (WARN_ON_ONCE(bkbd >= ARRAY_SIZE(names)))
+ return -EINVAL;
+ return sysfs_emit(buf, "%u (%s)\n", bkbd, names[bkbd]);
+}
+static DEVICE_ATTR_RO(keyboard_position);
+
+static struct attribute *yb9_kbdock_attrs[] = {
+ &dev_attr_keyboard_position.attr,
+ NULL,
+};
+
+static const struct attribute_group yb9_kbdock_group = {
+ .attrs = yb9_kbdock_attrs,
+};
+
+static const struct dmi_system_id yb9_kbdock_dmi_table[] = {
+ {
+ /* Lenovo Yoga Book 9 14IAH10 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "83KJ"),
+ },
+ },
+ { }
+};
+
+static int yb9_kbdock_probe(struct wmi_device *wdev, const void *ctx)
+{
+ enum yb9_guid_type type = (enum yb9_guid_type)(uintptr_t)ctx;
+ struct yb9_kbdock_priv *priv;
+ struct input_dev *input_dev;
+ struct wmi_device *qwdev;
+ int bkbd_init;
+ int err;
+
+ if (type == YB9_GUID_QUERY) {
+ if (!dmi_check_system(yb9_kbdock_dmi_table))
+ return -ENODEV;
+ mutex_lock(&yb9_query_lock);
+ yb9_query_wdev = wdev;
+ mutex_unlock(&yb9_query_lock);
+ return 0;
+ }
+
+ if (!dmi_check_system(yb9_kbdock_dmi_table))
+ return -ENODEV;
+
+ mutex_lock(&yb9_query_lock);
+ qwdev = yb9_query_wdev;
+ if (qwdev)
+ get_device(&qwdev->dev);
+ mutex_unlock(&yb9_query_lock);
+ if (!qwdev)
+ return -EPROBE_DEFER;
+
+ priv = devm_kzalloc(&wdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ put_device(&qwdev->dev);
+ return -ENOMEM;
+ }
+
+ input_dev = devm_input_allocate_device(&wdev->dev);
+ if (!input_dev) {
+ put_device(&qwdev->dev);
+ return -ENOMEM;
+ }
+
+ input_dev->name = "Lenovo Yoga Book 9 keyboard dock switch";
+ input_dev->phys = YB9_KBDOCK_EVENT_GUID "/input0";
+ input_dev->id.bustype = BUS_HOST;
+ input_dev->dev.parent = &wdev->dev;
+ input_set_capability(input_dev, EV_SW, SW_TABLET_MODE);
+
+ priv->input_dev = input_dev;
+ dev_set_drvdata(&wdev->dev, priv);
+
+ /*
+ * Query the initial dock state and preset the switch bit before
+ * input_register_device() so userspace never sees SW_TABLET_MODE = 0
+ * for a detached keyboard on first open.
+ */
+ bkbd_init = yb9_kbdock_query(wdev, qwdev);
+ put_device(&qwdev->dev);
+ if (bkbd_init >= 0) {
+ priv->bkbd = bkbd_init;
+ if (bkbd_init == BKBD_DETACHED)
+ __set_bit(SW_TABLET_MODE, input_dev->sw);
+ }
+
+ err = input_register_device(input_dev);
+ if (err) {
+ dev_err(&wdev->dev, "failed to register input device: %d\n", err);
+ return err;
+ }
+
+ err = devm_device_add_group(&wdev->dev, &yb9_kbdock_group);
+ if (err) {
+ dev_err(&wdev->dev, "failed to add sysfs group: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+
+static void yb9_kbdock_remove(struct wmi_device *wdev)
+{
+ mutex_lock(&yb9_query_lock);
+ if (wdev == yb9_query_wdev)
+ yb9_query_wdev = NULL;
+ mutex_unlock(&yb9_query_lock);
+}
+
+static const struct wmi_device_id yb9_kbdock_wmi_id_table[] = {
+ { .guid_string = YB9_KBDOCK_EVENT_GUID, .context = (void *)YB9_GUID_EVENT },
+ { .guid_string = YB9_KBDOCK_QUERY_GUID, .context = (void *)YB9_GUID_QUERY },
+ { }
+};
+MODULE_DEVICE_TABLE(wmi, yb9_kbdock_wmi_id_table);
+
+static struct wmi_driver yb9_kbdock_driver = {
+ .driver = {
+ .name = "lenovo-yb9-kbdock",
+ },
+ .id_table = yb9_kbdock_wmi_id_table,
+ .probe = yb9_kbdock_probe,
+ .remove = yb9_kbdock_remove,
+ .notify = yb9_kbdock_notify,
+};
+module_wmi_driver(yb9_kbdock_driver);
+
+MODULE_AUTHOR("Dave Carey <carvsdriver@gmail.com>");
+MODULE_DESCRIPTION("Lenovo Yoga Book 9 keyboard dock detection");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v6 3/4] HID: hid-msi: Add RGB control interface
From: sashiko-bot @ 2026-05-18 23:56 UTC (permalink / raw)
To: Derek J. Clark; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260518222935.1802071-4-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] Use-After-Free and NULL pointer dereference risks during RGB interface teardown.
- [High] Use-After-Free due to incorrect workqueue cancellation order.
- [Medium] Lifecycle mismatch of sysfs groups causes kernfs warnings on device removal.
- [Medium] Gamepad initialization is fully disabled if the RGB configuration read fails.
--
commit 1d7a0aec4b983c2c64bceb50fe253ae0e8e94c94
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi: Add RGB control interface
This commit adds an RGB control interface for MSI Claw devices, parsing
profile and effect data to mirror the RGB effects available in Windows.
> diff --git a/drivers/hid/hid-msi.c b/drivers/hid/hid-msi.c
> index e58d35dba5b40..4d267b896da72 100644
> --- a/drivers/hid/hid-msi.c
> +++ b/drivers/hid/hid-msi.c
[ ... ]
> @@ -846,16 +1372,44 @@ static void cfg_setup_fn(struct work_struct *work)
> return;
> }
>
> - /* Add sysfs attributes after we get the device state */
> - ret = devm_device_add_group(&drvdata->hdev->dev, &claw_gamepad_attr_group);
> + ret = claw_read_rgb_config(drvdata->hdev);
> if (ret) {
> dev_err(&drvdata->hdev->dev,
> - "Failed to setup device, can't create gamepad attrs: %d\n", ret);
> + "Failed to setup device, can't read RGB config: %d\n", ret);
> return;
> }
If claw_read_rgb_config() fails, it returns early and skips registering the
gamepad attributes. Should core gamepad functionality (like button mapping)
break if the cosmetic RGB feature fails to initialize?
> - drvdata->gamepad_registered = true;
> +
> + /* Add sysfs attributes after we get the device state */
> + if (!drvdata->gamepad_registered) {
> + ret = devm_device_add_group(&drvdata->hdev->dev, &claw_gamepad_attr_group);
> + if (ret) {
> + dev_err(&drvdata->hdev->dev,
> + "Failed to setup device, can't create gamepad attrs: %d\n", ret);
> + return;
> + }
> + drvdata->gamepad_registered = true;
> + }
> +
> + /* Add and enable RGB interface once we have the device state */
> + if (!drvdata->rgb_registered) {
> + ret = devm_led_classdev_multicolor_register(&drvdata->hdev->dev, &drvdata->led_mc);
> + if (ret) {
> + dev_err(&drvdata->hdev->dev,
> + "Failed to setup device, can't create led device: %d\n", ret);
> + return;
> + }
> +
> + ret = devm_device_add_group(drvdata->led_mc.led_cdev.dev, &claw_rgb_attr_group);
Will this trigger a kernfs warning on device removal?
The LED class device is unregistered via devres first, which calls
device_del() and implicitly removes all sysfs entries. This makes the
subsequent devres removal of claw_rgb_attr_group fail to find the directory,
triggering a "can not remove '...', no directory" warning.
Would it be safer to assign this group to drvdata->led_mc.led_cdev.groups
before registration instead of using devm_device_add_group()?
> + if (ret) {
> + dev_err(&drvdata->hdev->dev,
> + "Failed to setup device, can't create led attributes: %d\n", ret);
> + return;
> + }
> + drvdata->rgb_registered = true;
> + }
>
> kobject_uevent(&drvdata->hdev->dev.kobj, KOBJ_CHANGE);
> + kobject_uevent(&drvdata->led_mc.led_cdev.dev->kobj, KOBJ_CHANGE);
> }
[ ... ]
> @@ -979,10 +1553,14 @@ static void claw_remove(struct hid_device *hdev)
> return;
> }
>
> + /* Block writes to brightness/multi_intensity during teardown */
> + drvdata->led_mc.led_cdev.brightness_set = NULL;
Can this race with __led_set_brightness() in the LED subsystem? If the LED
core checks the brightness_set pointer and finds it valid, but gets preempted
while this runs without locking, could it then jump to a NULL pointer?
> cancel_delayed_work_sync(&drvdata->cfg_setup);
> cancel_delayed_work_sync(&drvdata->cfg_resume);
Since cfg_resume_fn() schedules cfg_setup, is it possible for cfg_setup to
be re-armed here?
If cfg_resume is currently running, cancelling cfg_setup first does nothing,
and then cfg_resume will queue cfg_setup again before completing. This could
leave cfg_setup pending after the driver data is freed.
> + cancel_delayed_work_sync(&drvdata->rgb_queue);
>
> drvdata->gamepad_registered = false;
> + drvdata->rgb_enabled = false;
>
> hid_hw_close(hdev);
> }
Because drvdata->rgb_registered remains true here, and the RGB sysfs
attributes are devres-managed (meaning they persist until after claw_remove
returns), could a concurrent userspace write pass the rgb_registered check
and call mod_delayed_work()?
This would re-arm rgb_queue after it was cancelled, leading to a
use-after-free when drvdata is eventually freed. Should
drvdata->rgb_registered = false be set before cancelling the workqueue?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518222935.1802071-1-derekjohn.clark@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v6 2/4] HID: hid-msi: Add M-key mapping attributes
From: sashiko-bot @ 2026-05-18 23:29 UTC (permalink / raw)
To: Derek J. Clark; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260518222935.1802071-3-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Data race and state desynchronization in `profile_pending` allows delayed ACKs to corrupt profile data.
- [High] Race window in `claw_hw_output_report()` causes spurious command timeouts.
- [High] Use-After-Free during module teardown due to incorrect delayed work cancellation order.
--
commit d45c51fc226fdd946c2d70a93c254be199300dc7
Author: Derek J. Clark <derekjohn.clark@gmail.com>
Subject: HID: hid-msi: Add M-key mapping attributes
This commit introduces M-key mapping attributes for the MSI Claw device.
It adds the ability to read and write profile mappings for two back buttons
(M1 and M2) via sysfs, using custom HID commands to communicate with the
hardware.
> diff --git a/drivers/hid/hid-msi.c b/drivers/hid/hid-msi.c
> index c79eb0bfeb776..e58d35dba5b40 100644
> --- a/drivers/hid/hid-msi.c
> +++ b/drivers/hid/hid-msi.c
[ ... ]
> struct claw_drvdata {
> /* MCU General Variables */
> + enum claw_profile_ack_pending profile_pending;
> struct completion send_cmd_complete;
> struct delayed_work cfg_resume;
> struct delayed_work cfg_setup;
This problem wasn't introduced by this patch, but does the cancellation order
of these delayed works cause a use-after-free regression during module
teardown?
In cfg_resume_fn(), cfg_setup is unconditionally queued via
schedule_delayed_work(). During module removal, if
cancel_delayed_work_sync(&drvdata->cfg_setup) is executed before
cancel_delayed_work_sync(&drvdata->cfg_resume), and cfg_resume_fn is
actively executing:
The first cancellation would return immediately because cfg_setup is not
yet pending. cfg_resume_fn would then queue cfg_setup. The second
cancellation would wait for cfg_resume_fn to finish.
Once the removal completes and drvdata is freed by devres, could the
newly queued cfg_setup fire 500ms later and dereference the freed
drvdata pointer?
[ ... ]
> +static int claw_profile_event(struct claw_drvdata *drvdata, struct claw_command_report *cmd_rep)
> +{
> + u8 *codes;
> + int i;
> +
> + switch (drvdata->profile_pending) {
> + case CLAW_M1_PENDING:
> + case CLAW_M2_PENDING:
> + codes = (drvdata->profile_pending == CLAW_M1_PENDING) ?
> + drvdata->m1_codes : drvdata->m2_codes;
> + for (i = 0; i < CLAW_KEYS_MAX; i++)
> + codes[i] = (cmd_rep->data[6 + i]);
> + break;
> + default:
> + dev_dbg(&drvdata->hdev->dev,
> + "Got profile event without changes pending from command: %x\n",
> + cmd_rep->cmd);
> + return -EINVAL;
> + }
> + drvdata->profile_pending = CLAW_NO_PENDING;
> +
> + return 0;
> +}
Is there a data race and potential state desynchronization with
profile_pending here?
drvdata->profile_pending is written under profile_mutex in process context
in claw_buttons_show(), but it is read and cleared locklessly here in the
atomic HID event handler.
If a request (like an M1 read) times out, profile_pending is cleared by the
sysfs thread. If a subsequent request then sets profile_pending to
CLAW_M2_PENDING, could a concurrently arriving delayed ACK for the original
M1 read cause this lockless handler to mistakenly parse the M1 payload into
drvdata->m2_codes?
This would reset profile_pending and prematurely wake the waiting thread,
corrupting the profile data.
[ ... ]
> +static int claw_buttons_store(struct device *dev, const char *buf, u8 mkey_idx)
> +{
[ ... ]
> +set_buttons:
> + scoped_guard(mutex, &drvdata->rom_mutex) {
> + ret = claw_hw_output_report(hdev, CLAW_COMMAND_TYPE_WRITE_PROFILE_DATA,
> + data, len, 25);
This problem wasn't introduced by this patch, but is there a race window in
claw_hw_output_report() that could cause spurious command timeouts?
Looking at claw_hw_output_report(), drvdata->waiting_for_ack is set to
true inside a cmd_lock critical section. Immediately after releasing the
spinlock, it calls reinit_completion(&drvdata->send_cmd_complete).
If the hardware responds exceptionally quickly, or if a delayed ACK from a
previous timed-out command arrives in the small window between the spinlock
release and the reinit_completion() call:
Could the interrupt handler clear waiting_for_ack and call complete(),
only for the main thread to immediately erase the completion event with
reinit_completion()?
This would cause wait_for_completion_interruptible_timeout() to block and
incorrectly return -ETIMEDOUT to userspace.
Should reinit_completion() be called before setting waiting_for_ack?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518222935.1802071-1-derekjohn.clark@gmail.com?part=2
^ 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