* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 16:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/dt-for-7.3 in local tree, thanks!
[2/6] dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
commit: c3600c97eb9c1a20a933a7fba08272955f7a7ccc
[3/6] dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
commit: 1d81cb06c30746448deb73b6ce9ceccc9fb6ca37
[4/6] dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
commit: 5e5e8a2e5a5e31fbe8858f08ef7ac44dff9ee351
[5/6] arm64: dts: allwinner: a100: Add LRADC node
commit: 8fa3a2bf77f0adb5440f25c3e2951543691e1536
[6/6] arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
commit: 7204944dcb8f1131b6303a5e9ca11128eb20ac21
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/6] [v5] gpiolib: turn off legacy interface by default
From: Geert Uytterhoeven @ 2026-06-29 16:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, John Paul Adrian Glaubitz,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Lee Jones, Pavel Machek, linux-sh, linux-kernel,
linux-input, linux-leds
In-Reply-To: <20260629130329.1291953-7-arnd@kernel.org>
On Mon, 29 Jun 2026 at 15:18, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> All users of the legacy interface now select CONFIG_GPIOLIB_LEGACY,
> so it can be turned off by default and only get built on platforms
> that still have one unconverted driver.
>
> Allow turning it on manually for compile testing, in order to keep
> the build coverage of the legacy drivers in allmodconfig and
> randconfig.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v5: added patch, now that we are getting closer to completing
> the series
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: srinivas pandruvada @ 2026-06-29 17:35 UTC (permalink / raw)
To: Wahid7852, linux-input, Zhang, Lixu; +Cc: jikos
In-Reply-To: <20260627224753.35075-1-wahidzk0091@gmail.com>
+Lixu
On Sun, 2026-06-28 at 04:17 +0530, Wahid7852 wrote:
> Some ISH firmware versions (observed on Tiger Lake LP, 8086:a0fc,
> GUID {33AECD58-B679-4E54-9BD9-A04D34F0C226}) periodically re-send an
> unsolicited HOSTIF_DM_ENUM_DEVICES response roughly every 79 seconds.
>
> The current guard collapses two distinct cases into one condition:
>
> if (!(response_flag) || init_done) -> bad packet + ish_hw_reset
>
> This incorrectly treats a valid post-init firmware announcement as a
> corrupted packet, triggering an ISH soft-reset and a full ISHTP
> re-initialisation cycle on each occurrence (~1100 times per day on
> affected hardware).
>
> Split the check: reject messages with no response flag as before, but
> simply discard valid ENUM_DEVICES messages that arrive after init is
> complete.
>
> Signed-off-by: Wahid <wahidzk0091@gmail.com>
Also you need first and last name for sign offs. Not sure this is
allowed format.
Thanks,
Srinivas
> ---
> drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> index 6d64008f2..ec5e8afe7 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
> @@ -113,8 +113,7 @@ static void process_recv(struct ishtp_cl
> *hid_ishtp_cl, void *recv_buf,
>
> switch (recv_msg->hdr.command & CMD_MASK) {
> case HOSTIF_DM_ENUM_DEVICES:
> - if ((!(recv_msg->hdr.command & ~CMD_MASK) ||
> - client_data->init_done)) {
> + if (!(recv_msg->hdr.command & ~CMD_MASK)) {
> ++client_data->bad_recv_cnt;
> report_bad_packet(hid_ishtp_cl,
> recv_msg,
> cur_pos,
> @@ -122,6 +121,8 @@ static void process_recv(struct ishtp_cl
> *hid_ishtp_cl, void *recv_buf,
> ish_hw_reset(ishtp_get_ishtp_device(
> hid_ishtp_cl));
> break;
> }
> + if (client_data->init_done)
> + break;
> client_data->hid_dev_count = (unsigned
> int)*payload;
> if (!client_data->hid_devices)
> client_data->hid_devices =
> devm_kcalloc(
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: Wahid7852 @ 2026-06-29 18:04 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada; +Cc: jikos, Lixu Zhang, Wahid Khan
In-Reply-To: <20260627224753.35075-1-wahidzk0091@gmail.com>
From: Wahid Khan <wahidzk0091@gmail.com>
Thanks. Correct sign-off should be: Signed-off-by: Wahid Khan <wahidzk0091@gmail.com>.
Should i send a follow up as v2 for this?
^ permalink raw reply
* Re: [PATCH v5 0/5] HID: asus: security fixes and more hardware support
From: Denis Benato @ 2026-06-29 18:00 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-kernel, linux-input, Benjamin Tissoires, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Antheas Kapenekakis, Connor Belli
In-Reply-To: <rr8s664r-5s34-1815-57ss-32p461sopp45@xreary.bet>
On 6/29/26 11:21, Jiri Kosina wrote:
> On Fri, 19 Jun 2026, Denis Benato wrote:
>
>> Hi all,
>>
>> I have added support for controlling the (way too bright) XG mobile
>> LEDs in hid-asus and added the i2c version of already supported
>> hardware that was probed only when it's a USB: these are two separate
>> features changes and are the only two that are not fixes for
>> pre-existing issue (see below).
>>
>> Auto-review bot has spotted a bunch of pre-existing problems alongside
>> problems in my own code therefore at this point I am going to fix the
>> more problems I can and including those fixes and improvements in this
>> patchset.
>>
>> For v4 I decided to follow Antheas' suggestion of reusing the existing
>> workqueue and by making it more generic I solved a good bunch of issues.
>>
>> The v5 iteration is simply me fixing a bunch of bugs in new code spotted
>> by the bot. Thanks for providing such a useful tool!
>>
>> On a side node this patchset has a few more warnings: specifically
>> "WARNING: Prefer kzalloc_obj over kzalloc with sizeof" but it's a false
>> positive as that would introduce sleeping calls in atomic contexts.
> Denis,
>
> thanks. Could you please flag which patches you'd prefer to go in still
> for 7.1 and which ones are not critical and could wait for 7.2? The whole
> lot is quite big.
Hi Jiri!
Patch 1 contains multiple fixes, mainly use of sleeping calls in atomic contexts:
I'd say slap it in 7.1 fixes.
Patch 2 is a minor improvement removing an OOM message to align the driver
to newer code where that would have been a flagged warning: probably a fix for
7.1 but there's no rush for this one.
Patch 3 is a logic fix, condition is very rare (not sure if even possible) but belongs
to 7.1 almost certainly.
Patch 4 new feature support: goes to 7.2.
Patch 5 unsure. It adds support to the backlight, but to properly do it I'll need
to wait for lamparray to be merged since autonomous mode must be disabled
to take effect. I'd say 7.2 just because of the missing lamparray. Merging in 7.1
has no downsides, yet IDK if putting in 7.1 violates some rule (probably yes?).
Please give a (very) quick read to the following link:
https://github.com/OpenGamingCollective/asusctl/issues/119#issuecomment-4723566635
This is something I am full of tickets for, probably we have reached the thousand
between discord, github and gitlab: very prominent issue and I'm eagerly waiting
for lamparray support to appear upstream.
Thanks,
Denis
> Thanks,
>
^ permalink raw reply
* Re: [PATCH v5 0/5] HID: asus: security fixes and more hardware support
From: Antheas Kapenekakis @ 2026-06-29 20:21 UTC (permalink / raw)
To: Denis Benato
Cc: Jiri Kosina, linux-kernel, linux-input, Benjamin Tissoires,
Luke D . Jones, Mateusz Schyboll, Denis Benato, Connor Belli
In-Reply-To: <ab282e6e-bc0a-4705-b25a-780d3ab33f5b@linux.dev>
On Mon, 29 Jun 2026 at 22:12, Denis Benato <denis.benato@linux.dev> wrote:
>
>
> On 6/29/26 11:21, Jiri Kosina wrote:
> > On Fri, 19 Jun 2026, Denis Benato wrote:
> >
> >> Hi all,
> >>
> >> I have added support for controlling the (way too bright) XG mobile
> >> LEDs in hid-asus and added the i2c version of already supported
> >> hardware that was probed only when it's a USB: these are two separate
> >> features changes and are the only two that are not fixes for
> >> pre-existing issue (see below).
> >>
> >> Auto-review bot has spotted a bunch of pre-existing problems alongside
> >> problems in my own code therefore at this point I am going to fix the
> >> more problems I can and including those fixes and improvements in this
> >> patchset.
> >>
> >> For v4 I decided to follow Antheas' suggestion of reusing the existing
> >> workqueue and by making it more generic I solved a good bunch of issues.
> >>
> >> The v5 iteration is simply me fixing a bunch of bugs in new code spotted
> >> by the bot. Thanks for providing such a useful tool!
> >>
> >> On a side node this patchset has a few more warnings: specifically
> >> "WARNING: Prefer kzalloc_obj over kzalloc with sizeof" but it's a false
> >> positive as that would introduce sleeping calls in atomic contexts.
> > Denis,
> >
> > thanks. Could you please flag which patches you'd prefer to go in still
> > for 7.1 and which ones are not critical and could wait for 7.2? The whole
> > lot is quite big.
> Hi Jiri!
>
> Patch 1 contains multiple fixes, mainly use of sleeping calls in atomic contexts:
> I'd say slap it in 7.1 fixes.
>
> Patch 2 is a minor improvement removing an OOM message to align the driver
> to newer code where that would have been a flagged warning: probably a fix for
> 7.1 but there's no rush for this one.
>
> Patch 3 is a logic fix, condition is very rare (not sure if even possible) but belongs
> to 7.1 almost certainly.
I would like to take my time on reviewing patch 4 in the next cycle.
The patch 5 does the backlight for the station? That looked _fine_ to
me but a second pair of eyes would be good because it is big.
Antheas
> Patch 4 new feature support: goes to 7.2.
>
> Patch 5 unsure. It adds support to the backlight, but to properly do it I'll need
> to wait for lamparray to be merged since autonomous mode must be disabled
> to take effect. I'd say 7.2 just because of the missing lamparray. Merging in 7.1
> has no downsides, yet IDK if putting in 7.1 violates some rule (probably yes?).
>
> Please give a (very) quick read to the following link:
> https://github.com/OpenGamingCollective/asusctl/issues/119#issuecomment-4723566635
>
> This is something I am full of tickets for, probably we have reached the thousand
> between discord, github and gitlab: very prominent issue and I'm eagerly waiting
> for lamparray support to appear upstream.
>
> Thanks,
> Denis
> > Thanks,
> >
>
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ignore post-init ENUM_DEVICES from firmware
From: srinivas pandruvada @ 2026-06-29 20:46 UTC (permalink / raw)
To: Wahid7852, linux-input; +Cc: jikos, Lixu Zhang
In-Reply-To: <20260629180419.383303-1-wahidzk0091@gmail.com>
On Mon, 2026-06-29 at 23:34 +0530, Wahid7852 wrote:
> From: Wahid Khan <wahidzk0091@gmail.com>
>
> Thanks. Correct sign-off should be: Signed-off-by: Wahid Khan
> <wahidzk0091@gmail.com>.
> Should i send a follow up as v2 for this?
Wait for Lixu's feedback, then send v2.
Thanks,
Srinivas
^ permalink raw reply
* [syzbot] [mm?] [usb?] [input?] INFO: rcu detected stall in sys_epoll_wait (9)
From: syzbot @ 2026-06-29 21:10 UTC (permalink / raw)
To: akpm, linux-input, linux-kernel, linux-mm, linux-usb,
pasha.tatashin, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 5a66900afbd6 Merge tag 'drm-fixes-2026-06-27' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10d4f4ea580000
kernel config: https://syzkaller.appspot.com/x/.config?x=77808e35144e725c
dashboard link: https://syzkaller.appspot.com/bug?extid=80b9ecbb1485ef700f5e
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=1383f861580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=110809fe580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3c925e1d8ab0/disk-5a66900a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1c3d8d08cec4/vmlinux-5a66900a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/af26ca154146/bzImage-5a66900a.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+80b9ecbb1485ef700f5e@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: (detected by 0, t=10506 jiffies, g=18441, q=1765 ncpus=2)
rcu: All QSes seen, last rcu_preempt kthread activity 10482 (4294969112-4294958630), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread starved for 10482 jiffies! g18441 f0x2 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:27672 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_timeout+0x127/0x280 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x1a9/0x900 kernel/rcu/tree.c:2123
rcu_gp_kthread+0x179/0x230 kernel/rcu/tree.c:2325
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:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 6473 Comm: rm Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/10/2026
RIP: 0010:_prb_read_valid+0x0/0x880 kernel/printk/printk_ringbuffer.c:2169
Code: e8 d5 3f b4 09 48 89 df e8 5d 77 91 00 e9 54 ff ff ff 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <41> 57 49 89 ff 41 56 49 89 f6 41 55 41 54 55 53 48 bb 00 00 00 00
RSP: 0000:ffffc90000a07e80 EFLAGS: 00000046
RAX: 0000000000000000 RBX: fffff52000140fd1 RCX: 0000000000000000
RDX: ffffc90000a07f50 RSI: ffffc90000a07ea8 RDI: ffffffff8e8f2100
RBP: ffffffff8e8f2100 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a07f50
R13: ffffc90000a07f90 R14: ffffc90000a07f50 R15: 0000000000000800
FS: 00007f80ef612c80(0000) GS:ffff8881241e0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f80ef7c74d0 CR3: 00000000274dc000 CR4: 00000000003526f0
Call Trace:
<IRQ>
prb_read_valid+0x78/0xa0 kernel/printk/printk_ringbuffer.c:2245
printk_get_next_message+0x15b/0x6c0 kernel/printk/printk.c:3052
console_emit_next_record kernel/printk/printk.c:3137 [inline]
console_flush_one_record+0x67c/0xe50 kernel/printk/printk.c:3269
console_flush_all kernel/printk/printk.c:3343 [inline]
__console_flush_and_unlock kernel/printk/printk.c:3373 [inline]
console_unlock+0x103/0x260 kernel/printk/printk.c:3413
vprintk_emit+0x407/0x6b0 kernel/printk/printk.c:2479
_printk+0xcf/0x110 kernel/printk/printk.c:2504
printk_stack_address arch/x86/kernel/dumpstack.c:70 [inline]
__show_trace_log_lvl+0x22d/0x2c4 arch/x86/kernel/dumpstack.c:282
show_trace_log_lvl arch/x86/kernel/dumpstack.c:319 [inline]
show_stack+0x47/0x70 arch/x86/kernel/dumpstack.c:337
sched_show_task kernel/sched/core.c:8184 [inline]
sched_show_task+0x471/0x610 kernel/sched/core.c:8159
show_state_filter+0xee/0x390 kernel/sched/core.c:8229
k_spec drivers/tty/vt/keyboard.c:659 [inline]
k_spec+0x100/0x140 drivers/tty/vt/keyboard.c:648
kbd_keycode drivers/tty/vt/keyboard.c:1565 [inline]
kbd_event+0xe4c/0x1b70 drivers/tty/vt/keyboard.c:1583
input_handle_events_default+0x119/0x1b0 drivers/input/input.c:2561
input_pass_values+0x753/0x880 drivers/input/input.c:128
input_event_dispose drivers/input/input.c:353 [inline]
input_handle_event+0x37f/0x1500 drivers/input/input.c:370
input_event drivers/input/input.c:396 [inline]
input_event+0x83/0xb0 drivers/input/input.c:391
hidinput_hid_event+0x5ec/0x24b0 drivers/hid/hid-input.c:1777
hid_process_event+0x4bc/0x5a0 drivers/hid/hid-core.c:1576
hid_input_array_field+0x303/0x6d0 drivers/hid/hid-core.c:1680
hid_process_report drivers/hid/hid-core.c:1730 [inline]
hid_report_raw_event+0xb43/0x1420 drivers/hid/hid-core.c:2095
__hid_input_report.constprop.0+0x349/0x470 drivers/hid/hid-core.c:2166
hid_irq_in+0x55d/0x710 drivers/hid/usbhid/hid-core.c:287
__usb_hcd_giveback_urb+0x38d/0x610 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
dummy_timer+0xda1/0x36c0 drivers/usb/gadget/udc/dummy_hcd.c:2005
__run_hrtimer kernel/time/hrtimer.c:2032 [inline]
__hrtimer_run_queues+0x462/0x9c0 kernel/time/hrtimer.c:2096
hrtimer_run_softirq+0x17d/0x2c0 kernel/time/hrtimer.c:2113
handle_softirqs+0x1ea/0x9b0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x162/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0xa3/0xc0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x70 kernel/kcov.c:217
Code: 2a 12 a9 00 01 ff 00 74 1b f6 c4 01 74 07 a9 00 00 ff 00 74 05 e9 11 81 96 09 8b 82 24 17 00 00 85 c0 74 f1 8b 82 f8 16 00 00 <83> f8 02 75 e6 48 8b 8a 00 17 00 00 8b 92 fc 16 00 00 48 8b 01 48
RSP: 0000:ffffc90004227968 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff88807e33ce10 RCX: 000000001435d025
RDX: ffff8880233f2540 RSI: ffffffff828626fa RDI: ffff88807eee8cc0
RBP: ffff88807eee8cc0 R08: 0000000000000001 R09: 0000000000002000
R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
R13: 0000000000000001 R14: 0000000000000000 R15: 1ffff92000844f30
__page_table_check_ptes_set+0x8a/0x4e0 mm/page_table_check.c:207
page_table_check_ptes_set include/linux/page_table_check.h:83 [inline]
set_ptes include/linux/pgtable.h:447 [inline]
set_pte_range+0x99b/0xbd0 mm/memory.c:5588
filemap_map_order0_folio mm/filemap.c:3874 [inline]
filemap_map_pages+0x756/0x1fe0 mm/filemap.c:3944
do_fault_around mm/memory.c:5818 [inline]
do_read_fault mm/memory.c:5851 [inline]
do_fault+0x985/0x1750 mm/memory.c:5994
do_pte_missing mm/memory.c:4566 [inline]
handle_pte_fault mm/memory.c:6379 [inline]
__handle_mm_fault+0x187d/0x2a00 mm/memory.c:6517
handle_mm_fault+0x37b/0xa30 mm/memory.c:6686
do_user_addr_fault+0x5a3/0x12f0 arch/x86/mm/fault.c:1343
handle_page_fault arch/x86/mm/fault.c:1483 [inline]
exc_page_fault+0x6f/0xd0 arch/x86/mm/fault.c:1536
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:595
RIP: 0033:0x7f80ef7c74d0
Code: Unable to access opcode bytes at 0x7f80ef7c74a6.
RSP: 002b:00007fff9128fe28 EFLAGS: 00010246
RAX: 0000000000000090 RBX: 00007f80ef9bba80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000000be
RBP: 00007fff91290150 R08: ffffffffffffffff R09: 0000000000000000
R10: 00007fff9128fe80 R11: 0000000000000246 R12: fffffffffffffff8
R13: 000000bb5f81c458 R14: 0000000000000000 R15: 00007f80ef9bd310
</TASK>
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a19061bd0
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:kworker/u8:10 state:I stack:27208 pid:6043 tgid:6043 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: 0x0 (events_unbound)
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
worker_thread+0x53b/0xe50 kernel/workqueue.c:3501
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>
task:syz-executor state:S stack:26920 pid:6044 tgid:6044 ppid:5640 task_flags:0x400100 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_wait+0x1a7/0x570 kernel/exit.c:1756
kernel_wait4+0x16d/0x280 kernel/exit.c:1910
__do_sys_wait4+0x161/0x170 kernel/exit.c:1938
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2d8d757fd7
RSP: 002b:00007fff82e8f620 EFLAGS: 00000202 ORIG_RAX: 000000000000003d
RAX: ffffffffffffffda RBX: 00005555903a2500 RCX: 00007f2d8d757fd7
RDX: 0000000040000000 RSI: 00007fff82e8f67c RDI: ffffffffffffffff
RBP: 00007fff82e8f67c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff82e8f6f8
R13: 0000000000000002 R14: 00007fff82e8f8d8 R15: 0000000000000000
</TASK>
task:kworker/u8:11 state:I stack:27096 pid:6045 tgid:6045 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: 0x0 (events_unbound)
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
worker_thread+0x53b/0xe50 kernel/workqueue.c:3501
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>
task:syz-executor state:S stack:26552 pid:6046 tgid:6046 ppid:5640 task_flags:0x400100 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_wait+0x1a7/0x570 kernel/exit.c:1756
kernel_wait4+0x16d/0x280 kernel/exit.c:1910
__do_sys_wait4+0x161/0x170 kernel/exit.c:1938
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4d4c357fd7
RSP: 002b:00007fffbb734a90 EFLAGS: 00000202 ORIG_RAX: 000000000000003d
RAX: ffffffffffffffda RBX: 00005555953cb500 RCX: 00007f4d4c357fd7
RDX: 0000000040000000 RSI: 00007fffbb734aec RDI: ffffffffffffffff
RBP: 00007fffbb734aec R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fffbb734b68
R13: 0000000000000002 R14: 00007fffbb734d48 R15: 0000000000000000
</TASK>
task:syz-executor state:S stack:26040 pid:6047 tgid:6047 ppid:5640 task_flags:0x400100 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_wait+0x1a7/0x570 kernel/exit.c:1756
kernel_wait4+0x16d/0x280 kernel/exit.c:1910
__do_sys_wait4+0x161/0x170 kernel/exit.c:1938
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4d26957fd7
RSP: 002b:00007fff2be14380 EFLAGS: 00000202 ORIG_RAX: 000000000000003d
RAX: ffffffffffffffda RBX: 0000555579950500 RCX: 00007f4d26957fd7
RDX: 0000000040000000 RSI: 00007fff2be143dc RDI: ffffffffffffffff
RBP: 00007fff2be143dc R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff2be14458
R13: 0000000000000002 R14: 00007fff2be14638 R15: 0000000000000000
</TASK>
task:syz-executor state:R running task stack:23528 pid:6048 tgid:6048 ppid:6035 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_nanosleep+0x113/0x500 kernel/time/hrtimer.c:2399
hrtimer_nanosleep+0x14f/0x350 kernel/time/hrtimer.c:2445
common_nsleep+0xa1/0xd0 kernel/time/posix-timers.c:1360
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1406 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1383 [inline]
__x64_sys_clock_nanosleep+0x336/0x480 kernel/time/posix-timers.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8eb955d68e
RSP: 002b:00007ffdb9c419c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
RAX: ffffffffffffffda RBX: 0000555559f80500 RCX: 00007f8eb955d68e
RDX: 00007ffdb9c41a20 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007ffdb9c41a8c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001388
R13: 00000000000927c0 R14: 00000000000344d1 R15: 00007ffdb9c41ae0
</TASK>
task:syz-executor state:R running task stack:23872 pid:6049 tgid:6049 ppid:6044 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_nanosleep+0x113/0x500 kernel/time/hrtimer.c:2399
hrtimer_nanosleep+0x14f/0x350 kernel/time/hrtimer.c:2445
common_nsleep+0xa1/0xd0 kernel/time/posix-timers.c:1360
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1406 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1383 [inline]
__x64_sys_clock_nanosleep+0x336/0x480 kernel/time/posix-timers.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2d8d75d68e
RSP: 002b:00007fff82e8f418 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
RAX: ffffffffffffffda RBX: 00005555903a2500 RCX: 00007f2d8d75d68e
RDX: 00007fff82e8f470 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007fff82e8f4dc R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001388
R13: 00000000000927c0 R14: 0000000000034625 R15: 00007fff82e8f530
</TASK>
task:syz-executor state:S stack:26520 pid:6050 tgid:6050 ppid:5640 task_flags:0x400100 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_wait+0x1a7/0x570 kernel/exit.c:1756
kernel_wait4+0x16d/0x280 kernel/exit.c:1910
__do_sys_wait4+0x161/0x170 kernel/exit.c:1938
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a52557fd7
RSP: 002b:00007ffc9b2ffdd0 EFLAGS: 00000202 ORIG_RAX: 000000000000003d
RAX: ffffffffffffffda RBX: 0000555580266500 RCX: 00007f4a52557fd7
RDX: 0000000040000000 RSI: 00007ffc9b2ffe2c RDI: ffffffffffffffff
RBP: 00007ffc9b2ffe2c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffc9b2ffea8
R13: 0000000000000002 R14: 00007ffc9b300088 R15: 0000000000000000
</TASK>
task:syz-executor state:R running task stack:23864 pid:6052 tgid:6052 ppid:6050 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_nanosleep+0x113/0x500 kernel/time/hrtimer.c:2399
hrtimer_nanosleep+0x14f/0x350 kernel/time/hrtimer.c:2445
common_nsleep+0xa1/0xd0 kernel/time/posix-timers.c:1360
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1406 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1383 [inline]
__x64_sys_clock_nanosleep+0x336/0x480 kernel/time/posix-timers.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a5255d68e
RSP: 002b:00007ffc9b2ffbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
RAX: ffffffffffffffda RBX: 0000555580266500 RCX: 00007f4a5255d68e
RDX: 00007ffc9b2ffc20 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007ffc9b2ffc8c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001388
R13: 00000000000927c0 R14: 0000000000034648 R15: 00007ffc9b2ffce0
</TASK>
task:syz-executor state:R running task stack:23960 pid:6053 tgid:6053 ppid:6046 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_nanosleep+0x113/0x500 kernel/time/hrtimer.c:2399
hrtimer_nanosleep+0x14f/0x350 kernel/time/hrtimer.c:2445
common_nsleep+0xa1/0xd0 kernel/time/posix-timers.c:1360
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1406 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1383 [inline]
__x64_sys_clock_nanosleep+0x336/0x480 kernel/time/posix-timers.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4d4c35d68e
RSP: 002b:00007fffbb734888 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
RAX: ffffffffffffffda RBX: 00005555953cb500 RCX: 00007f4d4c35d68e
RDX: 00007fffbb7348e0 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007fffbb73494c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000001388
R13: 00000000000927c0 R14: 0000000000034507 R15: 00007fffbb7349a0
</TASK>
task:syz-executor state:R running task stack:23928 pid:6056 tgid:6056 ppid:6047 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
do_nanosleep+0x113/0x500 kernel/time/hrtimer.c:2399
hrtimer_nanosleep+0x14f/0x350 kernel/time/hrtimer.c:2445
common_nsleep+0xa1/0xd0 kernel/time/posix-timers.c:1360
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1406 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1383 [inline]
__x64_sys_clock_nanosleep+0x336/0x480 kernel/time/posix-timers.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4d2695d68e
RSP: 002b:00007fff2be14178 EFLAGS: 00000246 ORIG_RAX: 00000000000000e6
RAX: ffffffffffffffda RBX: 0000555579950500 RCX: 00007f4d2695d68e
RDX: 00007fff2be141d0 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00007fff2be1423c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000064 R14: 0000000000034573 R15: 00007fff2be14290
</TASK>
task:udevd state:S stack:26552 pid:6062 tgid:6062 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a19069750
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27160 pid:6069 tgid:6069 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a19061bd0
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27464 pid:6072 tgid:6072 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a1907a870
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27832 pid:6073 tgid:6073 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a1907acf0
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27504 pid:6076 tgid:6076 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a1907a870
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27160 pid:6078 tgid:6078 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a19121cb0
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:udevd state:S stack:27200 pid:6079 tgid:6079 ppid:4977 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
ep_poll fs/eventpoll.c:2332 [inline]
do_epoll_wait+0x13f4/0x1770 fs/eventpoll.c:2811
__do_sys_epoll_wait fs/eventpoll.c:2819 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2814 [inline]
__x64_sys_epoll_wait+0x194/0x290 fs/eventpoll.c:2814
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd555fd2407
RSP: 002b:00007ffdc03e9e40 EFLAGS: 00000202 ORIG_RAX: 00000000000000e8
RAX: ffffffffffffffda RBX: 00007fd555f46880 RCX: 00007fd555fd2407
RDX: 0000000000000004 RSI: 00007ffdc03e9ed0 RDI: 0000000000000004
RBP: 0000555a18e2c2c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000202 R12: 0000555a190e6b10
R13: 00007ffdc03e9ed0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
task:krxrpcio/7001 state:S stack:30504 pid:6107 tgid:6107 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rxrpc_io_thread+0x1950/0x3820 net/rxrpc/io_thread.c:574
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>
task:krxrpcio/7001 state:S stack:30504 pid:6108 tgid:6108 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rxrpc_io_thread+0x1950/0x3820 net/rxrpc/io_thread.c:574
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>
task:krxrpcio/7001 state:S stack:29840 pid:6109 tgid:6109 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rxrpc_io_thread+0x1950/0x3820 net/rxrpc/io_thread.c:574
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>
task:kworker/R-bond0 state:I stack:31008 pid:6110 tgid:6110 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:krxrpcio/7001 state:S stack:30416 pid:6111 tgid:6111 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rxrpc_io_thread+0x1950/0x3820 net/rxrpc/io_thread.c:574
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>
task:krxrpcio/7001 state:S stack:30552 pid:6112 tgid:6112 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rxrpc_io_thread+0x1950/0x3820 net/rxrpc/io_thread.c:574
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>
task:kworker/R-bond0 state:I stack:29568 pid:6114 tgid:6114 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-bond0 state:I stack:30952 pid:6116 tgid:6116 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-bond0 state:I stack:30952 pid:6133 tgid:6133 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-bond0 state:I stack:30936 pid:6135 tgid:6135 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:29888 pid:6140 tgid:6140 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30952 pid:6141 tgid:6141 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6143 tgid:6143 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6144 tgid:6144 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30952 pid:6145 tgid:6145 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6146 tgid:6146 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6147 tgid:6147 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6148 tgid:6148 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30952 pid:6150 tgid:6150 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30952 pid:6155 tgid:6155 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:29840 pid:6156 tgid:6156 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30840 pid:6157 tgid:6157 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6167 tgid:6167 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:30952 pid:6168 tgid:6168 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:kworker/R-wg-cr state:I stack:31008 pid:6169 tgid:6169 ppid:2 task_flags:0x4208060 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
rescuer_thread+0xceb/0x14a0 kernel/workqueue.c:3678
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>
task:napi/wg0-0 state:S stack:29496 pid:6207 tgid:6207 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6208 tgid:6208 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:S stack:29496 pid:6210 tgid:6210 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:R running task stack:26872 pid:6211 tgid:6211 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:29496 pid:6213 tgid:6213 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:26872 pid:6214 tgid:6214 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6219 tgid:6219 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6220 tgid:6220 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:S stack:29496 pid:6221 tgid:6221 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:R running task stack:26872 pid:6222 tgid:6222 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:29496 pid:6223 tgid:6223 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:26872 pid:6224 tgid:6224 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:dhcpcd state:S stack:27160 pid:6226 tgid:6226 ppid:5272 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
poll_schedule_timeout.constprop.0+0xbe/0x1b0 fs/select.c:241
do_poll fs/select.c:965 [inline]
do_sys_poll+0x9a9/0xe90 fs/select.c:1015
__do_sys_ppoll fs/select.c:1112 [inline]
__se_sys_ppoll fs/select.c:1092 [inline]
__x64_sys_ppoll+0x2b5/0x350 fs/select.c:1092
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa1ee648407
RSP: 002b:00007fff01bf4cb0 EFLAGS: 00000202 ORIG_RAX: 000000000000010f
RAX: ffffffffffffffda RBX: 00007fa1ee5be780 RCX: 00007fa1ee648407
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 00005561a1a191e0
RBP: 00007fff01bf4ff0 R08: 0000000000000008 R09: 0000000000000000
R10: 00007fff01bf4ff0 R11: 0000000000000202 R12: 00005561739395e0
R13: 00005561a1a07d40 R14: 0000000000000000 R15: 00007fff01bf4da0
</TASK>
task:dhcpcd state:S stack:27160 pid:6227 tgid:6227 ppid:5272 task_flags:0x400140 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
schedule_hrtimeout_range_clock+0x2d0/0x310 kernel/time/sleep_timeout.c:207
poll_schedule_timeout.constprop.0+0xbe/0x1b0 fs/select.c:241
do_poll fs/select.c:965 [inline]
do_sys_poll+0x9a9/0xe90 fs/select.c:1015
__do_sys_ppoll fs/select.c:1112 [inline]
__se_sys_ppoll fs/select.c:1092 [inline]
__x64_sys_ppoll+0x2b5/0x350 fs/select.c:1092
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x870 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa1ee648407
RSP: 002b:00007fff01bf4cb0 EFLAGS: 00000202 ORIG_RAX: 000000000000010f
RAX: ffffffffffffffda RBX: 00007fa1ee5be780 RCX: 00007fa1ee648407
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 00005561a1a191e0
RBP: 00007fff01bf4ff0 R08: 0000000000000008 R09: 0000000000000000
R10: 00007fff01bf4ff0 R11: 0000000000000202 R12: 00005561739395e0
R13: 00005561a1a07d40 R14: 0000000000000000 R15: 00007fff01bf4da0
</TASK>
task:napi/wg0-0 state:S stack:29496 pid:6229 tgid:6229 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6230 tgid:6230 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:S stack:29496 pid:6231 tgid:6231 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg1-0 state:R running task stack:26872 pid:6232 tgid:6232 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:29496 pid:6233 tgid:6233 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg2-0 state:R running task stack:26872 pid:6234 tgid:6234 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6247 tgid:6247 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
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>
task:napi/wg0-0 state:S stack:29496 pid:6248 tgid:6248 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x125c/0x6730 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0xdd/0x2c0 kernel/sched/core.c:7326
napi_thread_wait net/core/dev.c:7823 [inline]
napi_threaded_poll+0x16f/0x4b0 net/core/dev.c:7891
---
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 v5 0/5] HID: asus: security fixes and more hardware support
From: Denis Benato @ 2026-06-29 19:04 UTC (permalink / raw)
To: Antheas Kapenekakis, Denis Benato
Cc: Jiri Kosina, linux-kernel, linux-input, Benjamin Tissoires,
Luke D . Jones, Mateusz Schyboll, Connor Belli
In-Reply-To: <CAGwozwFgw5aj1k_h60whKhTkzSf+vc=eEGvFz9sa-0rGoWOoww@mail.gmail.com>
On 6/29/26 22:21, Antheas Kapenekakis wrote:
> On Mon, 29 Jun 2026 at 22:12, Denis Benato <denis.benato@linux.dev> wrote:
>>
>> On 6/29/26 11:21, Jiri Kosina wrote:
>>> On Fri, 19 Jun 2026, Denis Benato wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have added support for controlling the (way too bright) XG mobile
>>>> LEDs in hid-asus and added the i2c version of already supported
>>>> hardware that was probed only when it's a USB: these are two separate
>>>> features changes and are the only two that are not fixes for
>>>> pre-existing issue (see below).
>>>>
>>>> Auto-review bot has spotted a bunch of pre-existing problems alongside
>>>> problems in my own code therefore at this point I am going to fix the
>>>> more problems I can and including those fixes and improvements in this
>>>> patchset.
>>>>
>>>> For v4 I decided to follow Antheas' suggestion of reusing the existing
>>>> workqueue and by making it more generic I solved a good bunch of issues.
>>>>
>>>> The v5 iteration is simply me fixing a bunch of bugs in new code spotted
>>>> by the bot. Thanks for providing such a useful tool!
>>>>
>>>> On a side node this patchset has a few more warnings: specifically
>>>> "WARNING: Prefer kzalloc_obj over kzalloc with sizeof" but it's a false
>>>> positive as that would introduce sleeping calls in atomic contexts.
>>> Denis,
>>>
>>> thanks. Could you please flag which patches you'd prefer to go in still
>>> for 7.1 and which ones are not critical and could wait for 7.2? The whole
>>> lot is quite big.
>> Hi Jiri!
>>
>> Patch 1 contains multiple fixes, mainly use of sleeping calls in atomic contexts:
>> I'd say slap it in 7.1 fixes.
>>
>> Patch 2 is a minor improvement removing an OOM message to align the driver
>> to newer code where that would have been a flagged warning: probably a fix for
>> 7.1 but there's no rush for this one.
>>
>> Patch 3 is a logic fix, condition is very rare (not sure if even possible) but belongs
>> to 7.1 almost certainly.
> I would like to take my time on reviewing patch 4 in the next cycle.
> The patch 5 does the backlight for the station? That looked _fine_ to
> me but a second pair of eyes would be good because it is big.
Mmhh I think you may have a mistake here? Patch 4 has your reviewed-by
and it's for the xgm led.
Patch 5 adds backlight for TUFs 2025 and 2026 models: asus is using
the (almost) same firmware as recent ROGs just i2c instead of usb,
so patch 5 add i2c to the list.
> Antheas
>
>> Patch 4 new feature support: goes to 7.2.
>>
>> Patch 5 unsure. It adds support to the backlight, but to properly do it I'll need
>> to wait for lamparray to be merged since autonomous mode must be disabled
>> to take effect. I'd say 7.2 just because of the missing lamparray. Merging in 7.1
>> has no downsides, yet IDK if putting in 7.1 violates some rule (probably yes?).
>>
>> Please give a (very) quick read to the following link:
>> https://github.com/OpenGamingCollective/asusctl/issues/119#issuecomment-4723566635
>>
>> This is something I am full of tickets for, probably we have reached the thousand
>> between discord, github and gitlab: very prominent issue and I'm eagerly waiting
>> for lamparray support to appear upstream.
>>
>> Thanks,
>> Denis
>>> Thanks,
>>>
^ permalink raw reply
* Re: [PATCH v5 0/5] HID: asus: security fixes and more hardware support
From: Antheas Kapenekakis @ 2026-06-29 21:13 UTC (permalink / raw)
To: Denis Benato
Cc: Denis Benato, Jiri Kosina, linux-kernel, linux-input,
Benjamin Tissoires, Luke D . Jones, Mateusz Schyboll,
Connor Belli
In-Reply-To: <abca959e-8757-426c-b641-f18cebfbeed5@gmail.com>
On Mon, 29 Jun 2026 at 23:11, Denis Benato <benato.denis96@gmail.com> wrote:
>
>
> On 6/29/26 22:21, Antheas Kapenekakis wrote:
> > On Mon, 29 Jun 2026 at 22:12, Denis Benato <denis.benato@linux.dev> wrote:
> >>
> >> On 6/29/26 11:21, Jiri Kosina wrote:
> >>> On Fri, 19 Jun 2026, Denis Benato wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I have added support for controlling the (way too bright) XG mobile
> >>>> LEDs in hid-asus and added the i2c version of already supported
> >>>> hardware that was probed only when it's a USB: these are two separate
> >>>> features changes and are the only two that are not fixes for
> >>>> pre-existing issue (see below).
> >>>>
> >>>> Auto-review bot has spotted a bunch of pre-existing problems alongside
> >>>> problems in my own code therefore at this point I am going to fix the
> >>>> more problems I can and including those fixes and improvements in this
> >>>> patchset.
> >>>>
> >>>> For v4 I decided to follow Antheas' suggestion of reusing the existing
> >>>> workqueue and by making it more generic I solved a good bunch of issues.
> >>>>
> >>>> The v5 iteration is simply me fixing a bunch of bugs in new code spotted
> >>>> by the bot. Thanks for providing such a useful tool!
> >>>>
> >>>> On a side node this patchset has a few more warnings: specifically
> >>>> "WARNING: Prefer kzalloc_obj over kzalloc with sizeof" but it's a false
> >>>> positive as that would introduce sleeping calls in atomic contexts.
> >>> Denis,
> >>>
> >>> thanks. Could you please flag which patches you'd prefer to go in still
> >>> for 7.1 and which ones are not critical and could wait for 7.2? The whole
> >>> lot is quite big.
> >> Hi Jiri!
> >>
> >> Patch 1 contains multiple fixes, mainly use of sleeping calls in atomic contexts:
> >> I'd say slap it in 7.1 fixes.
> >>
> >> Patch 2 is a minor improvement removing an OOM message to align the driver
> >> to newer code where that would have been a flagged warning: probably a fix for
> >> 7.1 but there's no rush for this one.
> >>
> >> Patch 3 is a logic fix, condition is very rare (not sure if even possible) but belongs
> >> to 7.1 almost certainly.
> > I would like to take my time on reviewing patch 4 in the next cycle.
> > The patch 5 does the backlight for the station? That looked _fine_ to
> > me but a second pair of eyes would be good because it is big.
> Mmhh I think you may have a mistake here? Patch 4 has your reviewed-by
> and it's for the xgm led.
>
> Patch 5 adds backlight for TUFs 2025 and 2026 models: asus is using
> the (almost) same firmware as recent ROGs just i2c instead of usb,
> so patch 5 add i2c to the list.
I want to review for the next cycle:
HID: asus: refactor the two workqueues and init sequence
Antheas
> > Antheas
> >
> >> Patch 4 new feature support: goes to 7.2.
> >>
> >> Patch 5 unsure. It adds support to the backlight, but to properly do it I'll need
> >> to wait for lamparray to be merged since autonomous mode must be disabled
> >> to take effect. I'd say 7.2 just because of the missing lamparray. Merging in 7.1
> >> has no downsides, yet IDK if putting in 7.1 violates some rule (probably yes?).
> >>
> >> Please give a (very) quick read to the following link:
> >> https://github.com/OpenGamingCollective/asusctl/issues/119#issuecomment-4723566635
> >>
> >> This is something I am full of tickets for, probably we have reached the thousand
> >> between discord, github and gitlab: very prominent issue and I'm eagerly waiting
> >> for lamparray support to appear upstream.
> >>
> >> Thanks,
> >> Denis
> >>> Thanks,
> >>>
>
^ permalink raw reply
* Re: [PATCH] HID: hiddev: keep state alive through disconnect unlock
From: Hillf Danton @ 2026-06-29 22:10 UTC (permalink / raw)
To: Yousef Alhouseen
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-usb,
linux-kernel, syzbot+563191a4939ddbfe73d4
In-Reply-To: <CAMuQ4bUuSP=J6Fv=TuzPL6Y34NC3v-rC-O8kGqh86gbUcF8H+g@mail.gmail.com>
[ feel free not to send top reply ]
On Mon, 29 Jun 2026 08:57:02 -0500 Yousef Alhouseen wrote:
> The missing interleaving is that mutex_unlock() clears the owner
> before taking wait_lock. A contender already spinning on existancelock
> can acquire it after that owner clear, reach the final-release path,
> and free hiddev before the disconnecting task reaches
> raw_spin_lock_irqsave(&lock->wait_lock, ...). It does not need to be
> woken by the disconnecting task.
>
In __mutex_unlock_slowpath() the wait_lock is taken because of MUTEX_FLAG_WAITERS
after clearing the lock owner, so it is bug in the mutex backyard instead if
mutex is freed without pending waiters handled.
^ permalink raw reply
* [PATCH] HID: corsair-void: Check size of status and firmware events before reading them
From: Stuart Hayhurst @ 2026-06-30 0:40 UTC (permalink / raw)
To: linux-input
Cc: Stuart Hayhurst, linux-kernel, Benjamin Tissoires, Jiri Kosina,
stable
Malformed status and firmware events could cause an out-of-bounds read since
the size wasn't being checked. Check the size and warn on unexpected values to
avoid this.
Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver")
Cc: stable@vger.kernel.org
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
---
drivers/hid/hid-corsair-void.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
index 5e9a5b8f7f16..fdcc4b8cd272 100644
--- a/drivers/hid/hid-corsair-void.c
+++ b/drivers/hid/hid-corsair-void.c
@@ -92,6 +92,9 @@
#define CORSAIR_VOID_STATUS_REPORT_ID 0x64
#define CORSAIR_VOID_FIRMWARE_REPORT_ID 0x66
+#define CORSAIR_VOID_STATUS_REPORT_SIZE 5
+#define CORSAIR_VOID_FIRMWARE_REPORT_SIZE 5
+
#define CORSAIR_VOID_USB_SIDETONE_REQUEST 0x1
#define CORSAIR_VOID_USB_SIDETONE_REQUEST_TYPE 0x21
#define CORSAIR_VOID_USB_SIDETONE_VALUE 0x200
@@ -742,6 +745,11 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
/* Description of packets are documented at the top of this file */
if (hid_report->id == CORSAIR_VOID_STATUS_REPORT_ID) {
+ if (size != CORSAIR_VOID_STATUS_REPORT_SIZE) {
+ hid_warn(hid_dev, "unexpected status report of size %d", size);
+ return 1;
+ }
+
drvdata->mic_up = FIELD_GET(CORSAIR_VOID_MIC_MASK, data[2]);
drvdata->connected = (data[3] == CORSAIR_VOID_WIRELESS_CONNECTED) ||
drvdata->is_wired;
@@ -750,6 +758,11 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
FIELD_GET(CORSAIR_VOID_CAPACITY_MASK, data[2]),
data[3], data[4]);
} else if (hid_report->id == CORSAIR_VOID_FIRMWARE_REPORT_ID) {
+ if (size != CORSAIR_VOID_FIRMWARE_REPORT_SIZE) {
+ hid_warn(hid_dev, "unexpected firmware report of size %d", size);
+ return 1;
+ }
+
drvdata->fw_receiver_major = data[1];
drvdata->fw_receiver_minor = data[2];
drvdata->fw_headset_major = data[3];
--
2.53.0
^ permalink raw reply related
* [PATCH] HID: corsair-void: Fix firmware event packet description
From: Stuart Hayhurst @ 2026-06-30 0:43 UTC (permalink / raw)
To: linux-input
Cc: Stuart Hayhurst, linux-kernel, Benjamin Tissoires, Jiri Kosina
The size was incorrectly stated as 4 bytes since the ID was missed out.
Add the ID in and correct the indices for the firmware versions.
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
---
drivers/hid/hid-corsair-void.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
index 5e9a5b8f7f16..ce92e3a9c058 100644
--- a/drivers/hid/hid-corsair-void.c
+++ b/drivers/hid/hid-corsair-void.c
@@ -51,20 +51,23 @@
/* Receiver report information: (ID 102) */
/* -------------------------------------------------------------------------- */
/*
- * When queried, the recevier responds with 4 bytes to describe the firmware
- * The first 2 bytes are for the receiver, the second 2 are the headset
+ * When queried, the receiver responds with 5 bytes to describe the firmware
+ * The first byte is the ID, then 2 bytes for the receiver, then 2 for the headset
* The headset firmware version will be 0 if no headset is connected
*
- * 0: Recevier firmware major version
+ * 0: Report ID
+ * 102 for the firmware packet
+ *
+ * 1: Receiver firmware major version
* Major version of the receiver's firmware
*
- * 1: Recevier firmware minor version
+ * 2: Receiver firmware minor version
* Minor version of the receiver's firmware
*
- * 2: Headset firmware major version
+ * 3: Headset firmware major version
* Major version of the headset's firmware
*
- * 3: Headset firmware minor version
+ * 4: Headset firmware minor version
* Minor version of the headset's firmware
*/
/* -------------------------------------------------------------------------- */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] HID: corsair-void: Check size of status and firmware events before reading them
From: sashiko-bot @ 2026-06-30 0:53 UTC (permalink / raw)
To: Stuart Hayhurst; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260630004003.579171-2-stuart.a.hayhurst@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Un-ratelimited kernel warning in a high-frequency packet processing path.
- [Medium] Overly strict bounds checking on report sizes incorrectly rejects valid, padded reports.
--
commit 867047370d14d44d5c13655e52c433ab8be9dd4a
Author: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
HID: corsair-void: Check size of status and firmware events before reading them
This commit adds bounds checking for status and firmware events in the
corsair-void HID driver to prevent out-of-bounds reads. If the size of the
event does not match the expected size, it logs a warning and returns early.
Cc: stable@vger.kernel.org
> diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
> index 5e9a5b8f7f167..fdcc4b8cd2720 100644
> --- a/drivers/hid/hid-corsair-void.c
> +++ b/drivers/hid/hid-corsair-void.c
[ ... ]
> @@ -742,6 +745,11 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
>
> /* Description of packets are documented at the top of this file */
> if (hid_report->id == CORSAIR_VOID_STATUS_REPORT_ID) {
> + if (size != CORSAIR_VOID_STATUS_REPORT_SIZE) {
[Severity: Medium]
Does this overly strict bounds check reject valid, padded reports?
It is common for USB host controllers to pad reports for 32-bit alignment,
or for newer headset firmwares to append data. Checking for an exact match
instead of a minimum length could cause the driver to silently drop these
packets and break headset functionality like battery status.
Would it be safer to check for a minimum length instead?
> + hid_warn(hid_dev, "unexpected status report of size %d", size);
[Severity: High]
Can a malfunctioning or malicious USB device flood the kernel log here?
Since this warning is un-ratelimited and occurs in the high-frequency packet
processing path of corsair_void_raw_event(), a device continuously sending
incorrectly sized reports could spam dmesg and potentially stall the CPU on
a slow serial console.
Should this use a ratelimited print, such as hid_warn_ratelimited() or
dev_warn_ratelimited()?
> + return 1;
> + }
> +
> drvdata->mic_up = FIELD_GET(CORSAIR_VOID_MIC_MASK, data[2]);
> drvdata->connected = (data[3] == CORSAIR_VOID_WIRELESS_CONNECTED) ||
> drvdata->is_wired;
> @@ -750,6 +758,11 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
> FIELD_GET(CORSAIR_VOID_CAPACITY_MASK, data[2]),
> data[3], data[4]);
> } else if (hid_report->id == CORSAIR_VOID_FIRMWARE_REPORT_ID) {
> + if (size != CORSAIR_VOID_FIRMWARE_REPORT_SIZE) {
[Severity: Medium]
This has the same strict bounds checking issue as the status report check
above. Does this also need to be converted to a minimum length check?
> + hid_warn(hid_dev, "unexpected firmware report of size %d", size);
[Severity: High]
This warning is also un-ratelimited. Can this be changed to use a
ratelimited print to prevent log flooding from malformed firmware reports?
> + return 1;
> + }
> +
> drvdata->fw_receiver_major = data[1];
> drvdata->fw_receiver_minor = data[2];
> drvdata->fw_headset_major = data[3];
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630004003.579171-2-stuart.a.hayhurst@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] HID: corsair-void: Fix firmware event packet description
From: sashiko-bot @ 2026-06-30 0:54 UTC (permalink / raw)
To: Stuart Hayhurst; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260630004323.589696-3-stuart.a.hayhurst@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The `corsair_void_raw_event()` function lacks a bounds check on the `size` of the incoming HID report, which can lead to an out-of-bounds read when accessing elements up to `data[4]`.
--
commit d2f977ace02628f486f8135ff442479be032fad6
Author: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
HID: corsair-void: Fix firmware event packet description
This commit updates the comment describing the firmware event packet in the
corsair-void HID driver. It corrects the stated size to 5 bytes to include
the ID, and updates the corresponding indices for the firmware versions.
> diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
> index 5e9a5b8f7f167..ce92e3a9c0580 100644
> --- a/drivers/hid/hid-corsair-void.c
> +++ b/drivers/hid/hid-corsair-void.c
> @@ -51,20 +51,23 @@
> /* Receiver report information: (ID 102) */
> /* -------------------------------------------------------------------------- */
> /*
> - * When queried, the recevier responds with 4 bytes to describe the firmware
> - * The first 2 bytes are for the receiver, the second 2 are the headset
> + * When queried, the receiver responds with 5 bytes to describe the firmware
> + * The first byte is the ID, then 2 bytes for the receiver, then 2 for the headset
> * The headset firmware version will be 0 if no headset is connected
> *
> - * 0: Recevier firmware major version
> + * 0: Report ID
> + * 102 for the firmware packet
> + *
> + * 1: Receiver firmware major version
> * Major version of the receiver's firmware
> *
> - * 1: Recevier firmware minor version
> + * 2: Receiver firmware minor version
> * Minor version of the receiver's firmware
> *
> - * 2: Headset firmware major version
> + * 3: Headset firmware major version
> * Major version of the headset's firmware
> *
> - * 3: Headset firmware minor version
> + * 4: Headset firmware minor version
> * Minor version of the headset's firmware
> */
[Severity: High]
This is a pre-existing issue, but does corsair_void_raw_event() lack a bounds
check on the size of the incoming HID report?
When the device sends a report matching the firmware report ID, it appears
the handler unconditionally accesses elements up to data[4]:
drivers/hid/hid-corsair-void.c:corsair_void_raw_event() {
...
drvdata->fw_receiver_major = data[1];
drvdata->fw_receiver_minor = data[2];
drvdata->fw_headset_major = data[3];
drvdata->fw_headset_minor = data[4];
...
}
If a malicious USB device sends a crafted HID descriptor defining a small
maximum report size, and then sends a 1-byte firmware report, can this lead
to an out-of-bounds read past the end of the report buffer?
It looks like the same issue might exist for the status report, which also
reads up to data[4] unconditionally:
drivers/hid/hid-corsair-void.c:corsair_void_raw_event() {
...
drvdata->mic_up = FIELD_GET(CORSAIR_VOID_MIC_MASK, data[2]);
drvdata->connected = (data[3] == CORSAIR_VOID_WIRELESS_CONNECTED) ||
drvdata->is_wired;
corsair_void_process_receiver(drvdata,
FIELD_GET(CORSAIR_VOID_CAPACITY_MASK, data[2]),
data[3], data[4]);
...
}
Could these out-of-bounds bytes be subsequently exposed to userspace via
sysfs attributes, resulting in a kernel memory information leak?
Could this also potentially trigger a kernel panic if the dynamically
allocated report buffer is small?
> /* -------------------------------------------------------------------------- */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630004323.589696-3-stuart.a.hayhurst@gmail.com?part=1
^ permalink raw reply
* [PATCH v2] HID: corsair-void: Check size of status and firmware events before reading them
From: Stuart Hayhurst @ 2026-06-30 1:06 UTC (permalink / raw)
To: linux-input
Cc: Stuart Hayhurst, linux-kernel, Benjamin Tissoires, Jiri Kosina,
stable
Malformed status and firmware events could cause an out-of-bounds read since
the size wasn't being checked. Check the size and warn on unexpected values to
avoid this.
Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver")
Cc: stable@vger.kernel.org
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
---
v1 -> v2:
- Ratelimit the warnings
- Accept packets larger than the expected size
---
drivers/hid/hid-corsair-void.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c
index 5e9a5b8f7f16..071a663a6c26 100644
--- a/drivers/hid/hid-corsair-void.c
+++ b/drivers/hid/hid-corsair-void.c
@@ -92,6 +92,9 @@
#define CORSAIR_VOID_STATUS_REPORT_ID 0x64
#define CORSAIR_VOID_FIRMWARE_REPORT_ID 0x66
+#define CORSAIR_VOID_STATUS_REPORT_SIZE 5
+#define CORSAIR_VOID_FIRMWARE_REPORT_SIZE 5
+
#define CORSAIR_VOID_USB_SIDETONE_REQUEST 0x1
#define CORSAIR_VOID_USB_SIDETONE_REQUEST_TYPE 0x21
#define CORSAIR_VOID_USB_SIDETONE_VALUE 0x200
@@ -742,6 +745,13 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
/* Description of packets are documented at the top of this file */
if (hid_report->id == CORSAIR_VOID_STATUS_REPORT_ID) {
+ if (size < CORSAIR_VOID_STATUS_REPORT_SIZE) {
+ hid_warn_ratelimited(hid_dev,
+ "unexpected status report of size %d",
+ size);
+ return 1;
+ }
+
drvdata->mic_up = FIELD_GET(CORSAIR_VOID_MIC_MASK, data[2]);
drvdata->connected = (data[3] == CORSAIR_VOID_WIRELESS_CONNECTED) ||
drvdata->is_wired;
@@ -750,6 +760,13 @@ static int corsair_void_raw_event(struct hid_device *hid_dev,
FIELD_GET(CORSAIR_VOID_CAPACITY_MASK, data[2]),
data[3], data[4]);
} else if (hid_report->id == CORSAIR_VOID_FIRMWARE_REPORT_ID) {
+ if (size < CORSAIR_VOID_FIRMWARE_REPORT_SIZE) {
+ hid_warn_ratelimited(hid_dev,
+ "unexpected firmware report of size %d",
+ size);
+ return 1;
+ }
+
drvdata->fw_receiver_major = data[1];
drvdata->fw_receiver_minor = data[2];
drvdata->fw_headset_major = data[3];
--
2.53.0
^ permalink raw reply related
* Re: [PATCH AUTOSEL 7.0-6.12] HID: i2c-hid: add reset quirk for BLTP7853 touchpad
From: Steve Yang @ 2026-06-30 4:52 UTC (permalink / raw)
To: stable, linux-input
Hello,
I can confirm that the BLTP7853 i2c-hid reset quirk fixes the internal
touchpad on my laptop.
Tested-by: Steve Yang <steveyang137@gmail.com>
Hardware:
MECHREVO XINGYAO Series / XINGYAO Series-P916F-PTL
BIOS: 1.00, 03/14/2026
Touchpad: BLTP7853:00 347D:7853 Touchpad
ACPI device: i2c-BLTP7853:00
Driver stack: i2c_hid_acpi + hid-multitouch
Broken kernel:
Linux 7.0.14-arch1-1
Symptoms before the fix:
The touchpad enumerated successfully and the HID report descriptor
was readable.
The input device was created and udev tagged it as ID_INPUT_TOUCHPAD=1.
However, the touchpad produced no input events in evtest.
Fixed kernel:
A kernel containing upstream commit a991aa5e89365ba1959fae6847fd288125b209e5
(HID: i2c-hid: add reset quirk for BLTP7853 touchpad)
After booting the fixed kernel, the internal touchpad works normally.
Thanks,
Steve
^ permalink raw reply
* [PATCH v7] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: 谢致邦 (XIE Zhibang) @ 2026-06-30 5:04 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov, bentiss, jikos
Cc: Yeking, dianders, linux-kernel, sashiko-bot, sashiko-reviews,
superm1
In-Reply-To: <360r0r52-n546-s91n-s51p-893o79415s74@xreary.bet>
Move the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI
and the new PRP0001 driver can use it. While refactoring, move the
blacklist check and the _DSM call to the top of probe() to avoid a
pointless alloc when the device is blacklisted or does not implement the
_DSM.
Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3,
are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but
lack "hid-descr-addr" from the _DSD and provide the HID descriptor
address only through an ACPI _DSM. The OF driver fails to probe them
because it requires hid-descr-addr. Add a new driver that handles these
devices by calling the shared _DSM helper.
Link: https://lore.kernel.org/tencent_F6FC553D1BB737FC00062AD0FEF43C580F0A@qq.com
Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
v2: Name the unused parameter and document why
acpi_device_fix_up_power() is skipped.
v3: Add a dev_warn() asking users to contact vendors for firmware
updates, and use existing locals in devm_kzalloc() and
acpi_device_fix_up_power().
v4: Double the power-up delay from 250ms to 500ms.
v5: Document why of_match_ptr() on the of_match_table is safe when
CONFIG_OF=n.
v6: Increase power-up delay from 500ms to 750ms. During cold boot on low
battery, 500ms causes non-fatal I2C transfer errors (-ENXIO). 750ms
fixes them.
v7: Drop I2C_HID_ACPI_PRP0001 Kconfig entry and build the driver under
CONFIG_I2C_HID_ACPI instead. Also wrap acpi_handle_err parameters across
two lines.
drivers/hid/i2c-hid/Makefile | 2 +-
drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c | 104 +++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-acpi.c | 52 +++--------
drivers/hid/i2c-hid/i2c-hid-acpi.h | 33 +++++++
4 files changed, 152 insertions(+), 39 deletions(-)
create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.h
diff --git a/drivers/hid/i2c-hid/Makefile b/drivers/hid/i2c-hid/Makefile
index 55bd5e0f35af..38d5d827f3ce 100644
--- a/drivers/hid/i2c-hid/Makefile
+++ b/drivers/hid/i2c-hid/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_I2C_HID_CORE) += i2c-hid.o
i2c-hid-objs = i2c-hid-core.o
i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
-obj-$(CONFIG_I2C_HID_ACPI) += i2c-hid-acpi.o
+obj-$(CONFIG_I2C_HID_ACPI) += i2c-hid-acpi.o i2c-hid-acpi-prp0001.o
obj-$(CONFIG_I2C_HID_OF) += i2c-hid-of.o
obj-$(CONFIG_I2C_HID_OF_ELAN) += i2c-hid-of-elan.o
obj-$(CONFIG_I2C_HID_OF_GOODIX) += i2c-hid-of-goodix.o
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
new file mode 100644
index 000000000000..d2cf4714ae7f
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HID over I2C driver for PRP0001 devices missing hid-descr-addr
+ *
+ * Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, use
+ * _HID "PRP0001" with _DSD compatible "hid-over-i2c" but lack "hid-descr-addr"
+ * from the _DSD. The HID descriptor address is provided only through an ACPI
+ * _DSM. The TPD0 node in the DSDT shows _DSM Function 1 returning 0x20.
+ *
+ * Copyright (C) 2026 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include "i2c-hid.h"
+#include "i2c-hid-acpi.h"
+
+static int i2c_hid_acpi_prp0001_power_up(struct i2chid_ops *ops)
+{
+ /* give the device time to power up */
+ msleep(750);
+ return 0;
+}
+
+static struct i2chid_ops i2c_hid_acpi_prp0001_ops = {
+ .power_up = i2c_hid_acpi_prp0001_power_up,
+ /*
+ * No .restore_sequence needed: the _DSM on these devices returns a
+ * constant (0x20) with no side effects, unlike some PNP0C50 _DSM
+ * implementations that switch the hardware between PS/2 and I2C modes.
+ */
+};
+
+static int i2c_hid_acpi_prp0001_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct acpi_device *adev;
+ u16 hid_descriptor_address;
+ int ret;
+
+ /* If hid-descr-addr is present, let i2c-hid-of handle it */
+ if (device_property_present(dev, "hid-descr-addr"))
+ return -ENODEV;
+
+ adev = ACPI_COMPANION(dev);
+ if (!adev)
+ return -ENODEV;
+
+ ret = i2c_hid_acpi_get_descriptor(adev);
+ if (ret < 0)
+ return ret;
+ dev_warn(dev,
+ "hid-descr-addr device property NOT found, using ACPI _DSM fallback. Contact vendor for firmware update!\n");
+ hid_descriptor_address = ret;
+
+ /*
+ * No acpi_device_fix_up_power() needed: TPD0 has no _PS0, _PS3, _PSC
+ * or _PRx methods and follows I2C bus power.
+ */
+ return i2c_hid_core_probe(client, &i2c_hid_acpi_prp0001_ops,
+ hid_descriptor_address, 0);
+}
+
+static const struct of_device_id i2c_hid_acpi_prp0001_of_match[] = {
+ { .compatible = "hid-over-i2c" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, i2c_hid_acpi_prp0001_of_match);
+
+static const struct i2c_device_id i2c_hid_acpi_prp0001_id[] = {
+ { .name = "hid-over-i2c" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, i2c_hid_acpi_prp0001_id);
+
+static struct i2c_driver i2c_hid_acpi_prp0001_driver = {
+ .driver = {
+ .name = "i2c_hid_acpi_prp0001",
+ .pm = &i2c_hid_core_pm,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ /*
+ * of_match_ptr() makes this NULL when CONFIG_OF=n, but that's
+ * fine: the I2C id_table with "hid-over-i2c" handles matching
+ * via client->name (set by acpi_set_modalias() from the _DSD
+ * compatible property).
+ */
+ .of_match_table = of_match_ptr(i2c_hid_acpi_prp0001_of_match),
+ },
+
+ .probe = i2c_hid_acpi_prp0001_probe,
+ .remove = i2c_hid_core_remove,
+ .shutdown = i2c_hid_core_shutdown,
+ .id_table = i2c_hid_acpi_prp0001_id,
+};
+
+module_i2c_driver(i2c_hid_acpi_prp0001_driver);
+
+MODULE_DESCRIPTION("HID over I2C driver for PRP0001 devices missing hid-descr-addr");
+MODULE_AUTHOR("谢致邦 (XIE Zhibang) <Yeking@Red54.com>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index abd700a101f4..13f977d6aab6 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -25,9 +25,9 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pm.h>
-#include <linux/uuid.h>
#include "i2c-hid.h"
+#include "i2c-hid-acpi.h"
struct i2c_hid_acpi {
struct i2chid_ops ops;
@@ -48,39 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
{ }
};
-/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
-static guid_t i2c_hid_guid =
- GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
- 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
-
-static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
-{
- struct acpi_device *adev = ihid_acpi->adev;
- acpi_handle handle = acpi_device_handle(adev);
- union acpi_object *obj;
- u16 hid_descriptor_address;
-
- if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
- return -ENODEV;
-
- obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
- ACPI_TYPE_INTEGER);
- if (!obj) {
- acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
- return -ENODEV;
- }
-
- hid_descriptor_address = obj->integer.value;
- ACPI_FREE(obj);
-
- return hid_descriptor_address;
-}
-
static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
- i2c_hid_acpi_get_descriptor(ihid_acpi);
+ i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
}
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
@@ -93,24 +65,28 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
static int i2c_hid_acpi_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
+ struct acpi_device *adev = ACPI_COMPANION(dev);
struct i2c_hid_acpi *ihid_acpi;
u16 hid_descriptor_address;
int ret;
- ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
+ if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
+ return -ENODEV;
+
+ ret = i2c_hid_acpi_get_descriptor(adev);
+ if (ret < 0)
+ return ret;
+ hid_descriptor_address = ret;
+
+ ihid_acpi = devm_kzalloc(dev, sizeof(*ihid_acpi), GFP_KERNEL);
if (!ihid_acpi)
return -ENOMEM;
- ihid_acpi->adev = ACPI_COMPANION(dev);
+ ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
- ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
- if (ret < 0)
- return ret;
- hid_descriptor_address = ret;
-
- acpi_device_fix_up_power(ihid_acpi->adev);
+ acpi_device_fix_up_power(adev);
return i2c_hid_core_probe(client, &ihid_acpi->ops,
hid_descriptor_address, 0);
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.h b/drivers/hid/i2c-hid/i2c-hid-acpi.h
new file mode 100644
index 000000000000..0bbed1853313
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _I2C_HID_ACPI_H
+#define _I2C_HID_ACPI_H
+
+#include <linux/acpi.h>
+#include <linux/uuid.h>
+
+static inline int i2c_hid_acpi_get_descriptor(struct acpi_device *adev)
+{
+ /* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
+ static const guid_t i2c_hid_guid =
+ GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
+ 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
+
+ acpi_handle handle = acpi_device_handle(adev);
+ union acpi_object *obj;
+ u16 addr;
+
+ obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid,
+ 1, 1, NULL, ACPI_TYPE_INTEGER);
+ if (!obj) {
+ acpi_handle_err(handle,
+ "Error _DSM call to get HID descriptor address failed\n");
+ return -ENODEV;
+ }
+
+ addr = obj->integer.value;
+ ACPI_FREE(obj);
+ return addr;
+}
+
+#endif
--
2.52.0
^ permalink raw reply related
* [PATCH] Input: maplemouse - set driver data before registering input device
From: Dmitry Torokhov @ 2026-06-30 5:47 UTC (permalink / raw)
To: linux-input, Adrian McMenamin; +Cc: Florian Fuchs, linux-kernel
Set maple driver data before calling input_register_device() to
ensure that it is available if the device is opened immediately and
the callback is triggered.
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/maplemouse.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
index c41182766538..0c8f7d1b02aa 100644
--- a/drivers/input/mouse/maplemouse.c
+++ b/drivers/input/mouse/maplemouse.c
@@ -88,6 +88,8 @@ static int probe_maple_mouse(struct device *dev)
mse->dev = input_dev;
mse->mdev = mdev;
+ maple_set_drvdata(mdev, mse);
+
input_set_drvdata(input_dev, mse);
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) |
@@ -103,12 +105,12 @@ static int probe_maple_mouse(struct device *dev)
goto fail_register;
mdev->driver = mdrv;
- maple_set_drvdata(mdev, mse);
return error;
fail_register:
input_free_device(input_dev);
+ maple_set_drvdata(mdev, NULL);
fail_nomem:
kfree(mse);
fail:
--
2.55.0.rc0.799.gd6f94ed593-goog
--
Dmitry
^ permalink raw reply related
* [PATCH] Input: maplecontrol - set driver data before registering input device
From: Dmitry Torokhov @ 2026-06-30 5:49 UTC (permalink / raw)
To: Adrian McMenamin, linux-input; +Cc: Florian Fuchs, linux-kernel
Set maple driver data before calling input_register_device() to
ensure that it is available if the device is opened immediately and
the callback is triggered.
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/joystick/maplecontrol.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
index 7f36f73844a9..6293b6e8148b 100644
--- a/drivers/input/joystick/maplecontrol.c
+++ b/drivers/input/joystick/maplecontrol.c
@@ -112,6 +112,8 @@ static int probe_maple_controller(struct device *dev)
pad->dev = idev;
pad->mdev = mdev;
+ maple_set_drvdata(mdev, pad);
+
idev->open = dc_pad_open;
idev->close = dc_pad_close;
@@ -146,7 +148,6 @@ static int probe_maple_controller(struct device *dev)
goto fail;
mdev->driver = mdrv;
- maple_set_drvdata(mdev, pad);
return 0;
--
2.55.0.rc0.799.gd6f94ed593-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: maplecontrol - set driver data before registering input device
From: sashiko-bot @ 2026-06-30 6:00 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <akNYib9hQFNN1fA9@google.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Medium] Dangling pointer to freed memory remains in driver data during the probe error path.
Pre-existing issues:
- [Critical] Invalid pointer derivation leading to NULL pointer dereference on device open.
- [High] Race condition exposing uninitialized driver data to hardware callbacks or userspace.
- [High] Race condition during device unbind leading to a NULL pointer dereference in the callback.
--
commit 32d63e0cc91d90b1d5a10a7764828de58888a240
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: maplecontrol - set driver data before registering input device
This commit modifies the maplecontrol driver to set the driver data before
calling input_register_device(). This ensures that the driver data is
available immediately if the device is opened and the callback is triggered.
> diff --git a/drivers/input/joystick/maplecontrol.c b/drivers/input/joystick/maplecontrol.c
> index 7f36f73844a91..6293b6e8148b3 100644
> --- a/drivers/input/joystick/maplecontrol.c
> +++ b/drivers/input/joystick/maplecontrol.c
> @@ -146,7 +148,6 @@ static int probe_maple_controller(struct device *dev)
> goto fail;
>
> mdev->driver = mdrv;
> - maple_set_drvdata(mdev, pad);
>
> return 0;
[Severity: Medium]
Since maple_set_drvdata(mdev, pad) was moved before input_register_device(),
does this leave a dangling pointer to freed memory in the error path?
If input_register_device() fails, it jumps to the fail block:
fail:
input_free_device(idev);
kfree(pad);
maple_set_drvdata(mdev, NULL);
return error;
This executes kfree(pad) before maple_set_drvdata(mdev, NULL), temporarily
leaving a dangling pointer in driver core structures. Should the order be
updated to clear the driver data before freeing pad?
[Severity: High]
This isn't a bug introduced by this patch, but does device removal race with
the maple DMA workqueue leading to a NULL pointer dereference?
When unbinding the device, remove_maple_controller() clears mdev->callback:
drivers/input/joystick/maplecontrol.c:remove_maple_controller() {
...
mdev->callback = NULL;
input_unregister_device(pad->dev);
maple_set_drvdata(mdev, NULL);
kfree(pad);
...
}
If the device is still open, input_unregister_device() synchronously invokes
dc_pad_close(), which inadvertently overwrites mdev->callback back to
dc_pad_callback:
drivers/input/joystick/maplecontrol.c:dc_pad_close() {
...
maple_getcond_callback(pad->mdev, dc_pad_callback, 0, MAPLE_FUNC_CONTROLLER);
...
}
The driver then executes maple_set_drvdata(mdev, NULL) and frees memory. A
pending maple DMA response running in the workqueue can then trigger
dc_pad_callback(), which fetches the now-NULL drvdata:
drivers/input/joystick/maplecontrol.c:dc_pad_callback() {
...
struct dc_pad *pad = maple_get_drvdata(mapledev);
struct input_dev *dev = pad->dev;
...
}
Could this result in dereferencing pad->dev and crashing the kernel if
triggered by unbinding the device while it is actively opened by local
userspace?
[Severity: High]
This is a pre-existing issue, but is there a race condition exposing
uninitialized driver data to hardware callbacks or userspace in other maple
drivers?
In drivers/input/keyboard/maple_keyb.c:probe_maple_kbd():
maple_getcond_callback(mdev, dc_kbd_callback, HZ/50, MAPLE_FUNC_KEYBOARD);
mdev->driver = mdrv;
maple_set_drvdata(mdev, kbd);
The callback is armed before the driver data is initialized, allowing the
interrupt handler to run and read a NULL pointer.
Similarly, in drivers/input/mouse/maplemouse.c:probe_maple_mouse():
error = input_register_device(input_dev);
if (error)
goto fail_register;
mdev->driver = mdrv;
maple_set_drvdata(mdev, mse);
Driver data for the mouse is set after device registration. If the hardware
callback fires immediately or userspace opens the device concurrently,
maple_get_drvdata() will return NULL and the callback could dereference it.
[Severity: Critical]
This is a pre-existing issue, but can this lead to a NULL pointer dereference
on device open?
Looking at dc_mouse_open() in drivers/input/mouse/maplemouse.c:
struct dc_mouse *mse = maple_get_drvdata(to_maple_dev(&dev->dev));
maple_getcond_callback(mse->mdev, dc_mouse_callback, HZ/50, MAPLE_FUNC_MOUSE);
The to_maple_dev macro uses container_of to subtract the offset of dev in
struct maple_device, and maple_get_drvdata immediately adds the offset back
via &mdev->dev. This mathematical cancellation means it effectively calls
dev_get_drvdata(&input_dev->dev).
However, the driver data was actually stored in the maple device (&mdev->dev),
not the input device. Thus, dev_get_drvdata returns NULL, and the subsequent
dereference of mse->mdev results in a direct NULL pointer dereference.
The same issue appears in drivers/input/mouse/maplemouse.c:dc_mouse_close():
struct dc_mouse *mse = maple_get_drvdata(to_maple_dev(&dev->dev));
--
Sashiko AI review · https://sashiko.dev/#/patchset/akNYib9hQFNN1fA9@google.com?part=1
^ permalink raw reply
* [PATCH] HID: rmi: check report length before trimming sentinel bytes
From: Pengpeng Hou @ 2026-06-30 6:52 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, Pengpeng Hou
rmi_check_sanity() trims trailing 0xff sentinel bytes, but its loop
reads data[valid_size - 1] before checking that valid_size is non-zero.
Reverse the condition so the length is proved before the last byte is
inspected.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/hid/hid-rmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index d4af17f..2bd781f 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -365,7 +365,7 @@ static int rmi_check_sanity(struct hid_device *hdev, u8 *data, int size)
* such reports here.
*/
- while ((data[valid_size - 1] == 0xff) && valid_size > 0)
+ while (valid_size > 0 && data[valid_size - 1] == 0xff)
valid_size--;
return valid_size;
^ permalink raw reply related
* [PATCH] Input: usbtouchscreen - validate Nexio reply length
From: Pengpeng Hou @ 2026-06-30 6:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Pengpeng Hou
nexio_init() accepts replies with actual_len == 1 and then reads buf[1]
to compare the embedded length.
Require at least two bytes before checking the embedded reply length.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/input/touchscreen/usbtouchscreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 0bbacb5..0e07bcc 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -1011,7 +1011,7 @@ static int nexio_init(struct usbtouch_usb *usbtouch)
ret = usb_bulk_msg(dev, usb_rcvbulkpipe(dev, input_ep),
buf, NEXIO_BUFSIZE, &actual_len,
NEXIO_TIMEOUT);
- if (ret < 0 || actual_len < 1 || buf[1] != actual_len)
+ if (ret < 0 || actual_len < 2 || buf[1] != actual_len)
continue;
switch (buf[0]) {
case 0x83: /* firmware version */
^ permalink raw reply related
* Re: [PATCH] Input: usbtouchscreen - validate Nexio reply length
From: sashiko-bot @ 2026-06-30 7:04 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <2026063007023179.2-ccfa108-0009-Input-usbtouchscreen---vali-pengpeng@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing `usb_kill_urb()` in `usbtouch_disconnect` for devices with `irq_always` leads to a Use-After-Free.
- [High] Missing URB restart in `usbtouch_reset_resume` for `irq_always` devices.
- [High] Heap out-of-bounds read in `usbtouch_process_multi()` when handling fragmented packets from a malicious device.
- [Medium] The driver unconditionally submits a shared ACK URB in the interrupt handler without checking if it is already active, leading to a WARN log-spam Denial of Service.
--
commit 5d3372d0fad0625b140375a0207438f22cdad247
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>
Input: usbtouchscreen - validate Nexio reply length
This commit updates nexio_init() to require at least two bytes of reply
data before checking the embedded reply length at buf[1]. This prevents
reading uninitialized or out-of-bounds data when actual_len is 1.
> diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
> index 0bbacb517c286..0e07bcce5f96b 100644
> --- a/drivers/input/touchscreen/usbtouchscreen.c
> +++ b/drivers/input/touchscreen/usbtouchscreen.c
> @@ -1011,7 +1011,7 @@ static int nexio_init(struct usbtouch_usb *usbtouch)
> ret = usb_bulk_msg(dev, usb_rcvbulkpipe(dev, input_ep),
> buf, NEXIO_BUFSIZE, &actual_len,
> NEXIO_TIMEOUT);
> - if (ret < 0 || actual_len < 1 || buf[1] != actual_len)
> + if (ret < 0 || actual_len < 2 || buf[1] != actual_len)
> continue;
> switch (buf[0]) {
> case 0x83: /* firmware version */
[Severity: High]
This isn't a bug introduced by this patch, but is it possible that the
polling URB will never be restarted for irq_always devices after a reset?
In usbtouch_reset_resume():
if (usbtouch->is_open)
return usb_submit_urb(usbtouch->irq, GFP_NOIO);
Unlike usbtouch_resume(), this misses the || usbtouch->type->irq_always
condition. If an irq_always device goes through a reset-resume cycle while
not actively opened by userspace, does this permanently break the hardware
polling contract and freeze the device until it is explicitly reopened?
[Severity: Critical]
This is a pre-existing issue, but does usbtouch_disconnect() have a
use-after-free risk for irq_always devices?
usbtouch_disconnect() calls:
usb_free_urb(usbtouch->irq);
if (usbtouch->type->exit)
usbtouch->type->exit(usbtouch);
usbtouch_free_buffers(interface_to_usbdev(intf), usbtouch);
kfree(usbtouch);
Since usbtouch_close() omits calling usb_kill_urb() for irq_always devices,
and usb_free_urb() only decrements the reference count without cancelling
the in-flight URB, the URB remains active.
When usbtouch_disconnect() returns, usb_disable_interface() will forcibly
cancel active URBs, triggering the completion handler usbtouch_irq():
struct usbtouch_usb *usbtouch = urb->context;
struct device *dev = &usbtouch->interface->dev;
Won't this completion handler access the already-freed usbtouch context
upon normal device unbind or unplug?
[Severity: High]
This isn't a bug introduced by this patch, but does usbtouch_process_multi()
properly validate bounds against the actual packet length?
tmp = pkt_len - usbtouch->buf_len;
if (usbtouch->buf_len + tmp >= usbtouch->type->rept_size)
goto out_flush_buf;
memcpy(usbtouch->buffer + usbtouch->buf_len, pkt, tmp);
If a device advertises a small wMaxPacketSize, the usbtouch->data buffer
is allocated small. When calculating tmp to read from the current URB
payload pkt, it doesn't verify that the received data length is at least
tmp.
If tmp is greater than the received length, will this memcpy() read past
the end of the newly received data and out of the bounds of the small heap
allocation?
[Severity: Medium]
This is a pre-existing issue, but can the unconditional submission of
the ACK URB lead to a log-spam denial of service?
In nexio_read_data():
/* send ACK */
ret = usb_submit_urb(priv->ack, GFP_ATOMIC);
if (ret)
dev_warn(dev, "Failed to submit ACK URB: %d\n", ret);
If a device sends rapid touch packets via the bulk IN endpoint faster
than they can be acknowledged, the driver will attempt to submit the
already-active ACK URB.
Since the USB core rejects resubmitting an active URB and emits a kernel
warning, could a malicious or buggy device spam IN packets to trigger a
continuous stream of kernel WARN stack traces?
--
Sashiko AI review · https://sashiko.dev/#/patchset/2026063007023179.2-ccfa108-0009-Input-usbtouchscreen---vali-pengpeng@iscas.ac.cn?part=1
^ permalink raw reply
* Re: [PATCH] HID: rmi: check report length before trimming sentinel bytes
From: sashiko-bot @ 2026-06-30 7:05 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <2026063007016439.1-ccfa108-0006-HID-rmi-check-report-length-pengpeng@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] `rmi_hid_write_block` writes data into a dynamically allocated heap buffer `data->writeReport` without verifying that the requested transfer length fits within the allocation.
- [High] `rmi_hid_read_block` trusts an attacker-controlled length field from the device report to read from the dynamically allocated `data->readReport` buffer, leading to an out-of-bounds read of kernel memory.
--
commit 5629c16e6055ea1ed7974ee398f60300987bc662
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>
HID: rmi: check report length before trimming sentinel bytes
rmi_check_sanity() trims trailing 0xff sentinel bytes, but its loop
reads data[valid_size - 1] before checking that valid_size is non-zero.
Reverse the condition so the length is proved before the last byte is
inspected.
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index d4af17fdba467..2bd781f1e0f53 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -365,7 +365,7 @@ static int rmi_check_sanity(struct hid_device *hdev, u8 *data, int size)
> * such reports here.
> */
>
> - while ((data[valid_size - 1] == 0xff) && valid_size > 0)
> + while (valid_size > 0 && data[valid_size - 1] == 0xff)
> valid_size--;
>
> return valid_size;
[Severity: High]
This is a pre-existing issue, but does this code overflow the dynamically
allocated data->writeReport buffer?
drivers/hid/hid-rmi.c:rmi_hid_write_block() {
...
data->writeReport[2] = addr & 0xFF;
data->writeReport[3] = (addr >> 8) & 0xFF;
memcpy(&data->writeReport[4], buf, len);
...
}
A malicious HID device can present a small output_report_size in its HID
descriptor, which determines the size of the data->writeReport allocation.
By sending parameters that cause the RMI core to perform a large block write,
can the device force rmi_hid_write_block() to process a len that vastly
exceeds the allocated buffer size?
[Severity: High]
This isn't a bug introduced by this patch, but could this memcpy() result in
an out-of-bounds read from the data->readReport buffer?
drivers/hid/hid-rmi.c:rmi_hid_read_block() {
...
read_input_count = data->readReport[1];
memcpy(buf + bytes_read, &data->readReport[2],
min(read_input_count, bytes_needed));
...
}
The function reads read_input_count directly from the incoming HID report
without validating it against the size of the data->readReport allocation
(data->input_report_size).
Could a malicious device specify a small input_report_size in its HID
descriptor but send a large read_input_count byte in the report, causing
the memcpy() to over-read the kernel heap?
--
Sashiko AI review · https://sashiko.dev/#/patchset/2026063007016439.1-ccfa108-0006-HID-rmi-check-report-length-pengpeng@iscas.ac.cn?part=1
^ 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