[syzbot] [hwmon?] KASAN: slab-out-of-bounds Read in aqc_raw_event

[syzbot] [hwmon?] KASAN: slab-out-of-bounds Read in aqc_raw_event

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    e1e6e541c5c9 Merge tag 'thunderbolt-for-v7.3-rc1' of ssh:/..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=16086e79580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8bdeea7ee6735f91
dashboard link: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
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=14737679580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15a22549580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3b0a1f8e6a1f/disk-e1e6e541.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f98d855e85e8/vmlinux-e1e6e541.xz
kernel image: https://storage.googleapis.com/syzbot-assets/db2c3a41df6d/bzImage-e1e6e541.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-out-of-bounds in get_unaligned_be16 include/linux/unaligned.h:48 [inline]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0

CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted syzkaller #0 PREEMPT(lazy) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x13d/0x4b0 mm/kasan/report.c:482
 kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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+0xdb2/0x36f0 drivers/usb/gadget/udc/dummy_hcd.c:2019
 __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+0x1dd/0x990 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x160/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+0x8f/0xb0 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:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:64
Code: 60 ab 01 e9 83 f7 02 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 23 ef 09 00 fb f4 <c3> cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
RSP: 0018:ffffc9000013fe10 EFLAGS: 00000246
RAX: 000000000004b053 RBX: ffff8881022d9e00 RCX: ffffffff877c9945
RDX: 0000000000000000 RSI: ffffffff890f4061 RDI: ffffffff87b15700
RBP: ffffed102045b3c0 R08: 0000000000000001 R09: ffffed103eae670d
R10: ffff8881f573386b R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 1ffff92000027fc6 R15: dffffc0000000000
 arch_safe_halt arch/x86/include/asm/paravirt.h:62 [inline]
 default_idle+0x9/0x10 arch/x86/kernel/process.c:768
 default_idle_call+0x6c/0xb0 kernel/sched/idle.c:122
 cpuidle_idle_call kernel/sched/idle.c:199 [inline]
 do_idle+0x3a7/0x5b0 kernel/sched/idle.c:355
 cpu_startup_entry+0x4f/0x60 kernel/sched/idle.c:454
 start_secondary+0x21d/0x2d0 arch/x86/kernel/smpboot.c:312
 common_startup_64+0x13e/0x158
 </TASK>

Allocated by task 23:
 kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
 kasan_save_track+0x14/0x30 mm/kasan/common.c:78
 poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
 __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:415
 kasan_kmalloc include/linux/kasan.h:263 [inline]
 __do_kmalloc_node mm/slub.c:5334 [inline]
 __kmalloc_noprof+0x309/0x7c0 mm/slub.c:5359
 _kmalloc_noprof include/linux/slab.h:992 [inline]
 hcd_buffer_alloc+0x1f5/0x290 drivers/usb/core/buffer.c:134
 usb_alloc_coherent+0x5f/0xa0 drivers/usb/core/usb.c:1011
 hid_alloc_buffers drivers/hid/usbhid/hid-core.c:859 [inline]
 usbhid_start+0x5cf/0x23a0 drivers/hid/usbhid/hid-core.c:1108
 hid_hw_start+0x65/0x140 drivers/hid/hid-core.c:2428
 aqc_probe+0x1a5/0x3510 drivers/hwmon/aquacomputer_d5next.c:1536
 __hid_device_probe drivers/hid/hid-core.c:2829 [inline]
 hid_device_probe+0x50e/0x800 drivers/hid/hid-core.c:2866
 call_driver_probe drivers/base/dd.c:628 [inline]
 really_probe+0x241/0xa60 drivers/base/dd.c:706
 __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
 driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
 __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
 bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
 __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
 device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
 bus_probe_device+0x64/0x160 drivers/base/bus.c:620
 device_add+0x121d/0x1970 drivers/base/core.c:3772
 hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3010
 usbhid_probe+0xa64/0x10b0 drivers/hid/usbhid/hid-core.c:1452
 usb_probe_interface+0x386/0x9b0 drivers/usb/core/driver.c:399
 call_driver_probe drivers/base/dd.c:628 [inline]
 really_probe+0x241/0xa60 drivers/base/dd.c:706
 __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
 driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
 __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
 bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
 __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
 device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
 bus_probe_device+0x64/0x160 drivers/base/bus.c:620
 device_add+0x121d/0x1970 drivers/base/core.c:3772
 usb_set_configuration+0xd97/0x1c60 drivers/usb/core/message.c:2268
 usb_generic_driver_probe+0xa1/0xe0 drivers/usb/core/generic.c:250
 usb_probe_device+0xef/0x400 drivers/usb/core/driver.c:293
 call_driver_probe drivers/base/dd.c:628 [inline]
 really_probe+0x241/0xa60 drivers/base/dd.c:706
 __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
 driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
 __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
 bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
 __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
 device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
 bus_probe_device+0x64/0x160 drivers/base/bus.c:620
 device_add+0x121d/0x1970 drivers/base/core.c:3772
 usb_new_device.part.0+0xcc2/0x1686 drivers/usb/core/hub.c:2708
 usb_new_device drivers/usb/core/hub.c:5833 [inline]
 hub_port_connect drivers/usb/core/hub.c:5580 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5720 [inline]
 port_event drivers/usb/core/hub.c:5884 [inline]
 hub_event.cold+0x51a/0xe9d drivers/usb/core/hub.c:5966
 process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
 process_scheduled_works kernel/workqueue.c:3405 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at ffff888108aba200
 which belongs to the cache kmalloc-96 of size 96
The buggy address is located 22 bytes to the right of
 allocated 65-byte region [ffff888108aba200, ffff888108aba241)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888108aba680 pfn:0x108aba
flags: 0x200000000000200(workingset|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000200 ffff888100041280 ffff8881000401c8 ffffea00046bf250
raw: ffff888108aba680 0000000800200017 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2c00(GFP_NOIO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11, tgid 11 (kworker/0:1), ts 4259009323, free_ts 4258897945
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1859
 prep_new_page mm/page_alloc.c:1867 [inline]
 get_page_from_freelist+0xf25/0x3400 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x28f/0x2b90 mm/page_alloc.c:5304
 alloc_slab_page mm/slub.c:3266 [inline]
 allocate_slab mm/slub.c:3380 [inline]
 new_slab+0xa2/0x670 mm/slub.c:3426
 refill_objects+0xe3/0x410 mm/slub.c:7310
 refill_sheaf mm/slub.c:2804 [inline]
 __pcs_replace_empty_main+0x376/0x680 mm/slub.c:4675
 alloc_from_pcs mm/slub.c:4773 [inline]
 slab_alloc_node mm/slub.c:4905 [inline]
 __kmalloc_cache_node_noprof+0x4b3/0x670 mm/slub.c:5504
 _kmalloc_node_noprof include/linux/slab.h:1193 [inline]
 __get_vm_area_node+0x101/0x330 mm/vmalloc.c:3237
 __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4064
 __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4165
 __vmalloc_noprof+0xa3/0x120 mm/vmalloc.c:4181
 pcpu_mem_zalloc+0x54/0xb0 mm/percpu.c:512
 pcpu_alloc_chunk mm/percpu.c:1449 [inline]
 pcpu_create_chunk+0x119/0x620 mm/percpu-vm.c:338
 pcpu_balance_populated mm/percpu.c:2073 [inline]
 pcpu_balance_workfn+0xb2c/0xdc0 mm/percpu.c:2215
 process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
 process_scheduled_works kernel/workqueue.c:3405 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
page last free pid 11 tgid 11 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1406 [inline]
 __free_frozen_pages+0x716/0xf50 mm/page_alloc.c:2950
 __kasan_populate_vmalloc_do mm/kasan/shadow.c:393 [inline]
 __kasan_populate_vmalloc+0x1ea/0x210 mm/kasan/shadow.c:424
 kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
 alloc_vmap_area+0x95d/0x2bb0 mm/vmalloc.c:2145
 __get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3248
 __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4064
 __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4165
 __vmalloc_noprof+0xa3/0x120 mm/vmalloc.c:4181
 pcpu_mem_zalloc+0x54/0xb0 mm/percpu.c:512
 pcpu_alloc_chunk mm/percpu.c:1444 [inline]
 pcpu_create_chunk+0xce/0x620 mm/percpu-vm.c:338
 pcpu_balance_populated mm/percpu.c:2073 [inline]
 pcpu_balance_workfn+0xb2c/0xdc0 mm/percpu.c:2215
 process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
 process_scheduled_works kernel/workqueue.c:3405 [inline]
 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
 kthread+0x370/0x450 kernel/kthread.c:436
 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff888108aba100: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
 ffff888108aba180: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
>ffff888108aba200: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
                                                 ^
 ffff888108aba280: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
 ffff888108aba300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================
----------------
Code disassembly (best guess), 3 bytes skipped:
   0:	e9 83 f7 02 00       	jmp    0x2f788
   5:	0f 1f 00             	nopl   (%rax)
   8:	90                   	nop
   9:	90                   	nop
   a:	90                   	nop
   b:	90                   	nop
   c:	90                   	nop
   d:	90                   	nop
   e:	90                   	nop
   f:	90                   	nop
  10:	90                   	nop
  11:	90                   	nop
  12:	90                   	nop
  13:	90                   	nop
  14:	90                   	nop
  15:	90                   	nop
  16:	90                   	nop
  17:	90                   	nop
  18:	f3 0f 1e fa          	endbr64
  1c:	66 90                	xchg   %ax,%ax
  1e:	0f 00 2d 23 ef 09 00 	verw   0x9ef23(%rip)        # 0x9ef48
  25:	fb                   	sti
  26:	f4                   	hlt
* 27:	c3                   	ret <-- trapping instruction
  28:	cc                   	int3
  29:	cc                   	int3
  2a:	cc                   	int3
  2b:	cc                   	int3
  2c:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
  33:	00 00 00
  36:	66 90                	xchg   %ax,%ax
  38:	90                   	nop
  39:	90                   	nop
  3a:	90                   	nop
  3b:	90                   	nop
  3c:	90                   	nop


---
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

Re: [syzbot] [hwmon?] KASAN: slab-out-of-bounds Read in aqc_raw_event

[Guenter Roeck]

Aleksa,

On 8/21/26 20:06, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    e1e6e541c5c9 Merge tag 'thunderbolt-for-v7.3-rc1' of ssh:/..
> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> console output: https://syzkaller.appspot.com/x/log.txt?x=16086e79580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8bdeea7ee6735f91
> dashboard link: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> 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=14737679580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15a22549580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/3b0a1f8e6a1f/disk-e1e6e541.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f98d855e85e8/vmlinux-e1e6e541.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/db2c3a41df6d/bzImage-e1e6e541.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in get_unaligned_be16 include/linux/unaligned.h:48 [inline]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327

The problem is that syzkaller sends a bad (short) report.
aqc_raw_event() needs to validate the report size and bail out
if it is short. The fix should be straightforard if it is known
what the minimum report size is. D5NEXT_CTRL_REPORT_SIZE ?

Thanks,
Guenter

> Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> 
> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted syzkaller #0 PREEMPT(lazy)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
> Call Trace:
>   <IRQ>
>   __dump_stack lib/dump_stack.c:94 [inline]
>   dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
>   print_address_description mm/kasan/report.c:378 [inline]
>   print_report+0x13d/0x4b0 mm/kasan/report.c:482
>   kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
>   get_unaligned_be16 include/linux/unaligned.h:48 [inline]
>   aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
>   aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
>   __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
>   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+0xdb2/0x36f0 drivers/usb/gadget/udc/dummy_hcd.c:2019
>   __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+0x1dd/0x990 kernel/softirq.c:622
>   __do_softirq kernel/softirq.c:656 [inline]
>   invoke_softirq kernel/softirq.c:496 [inline]
>   __irq_exit_rcu+0x160/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+0x8f/0xb0 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:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:64
> Code: 60 ab 01 e9 83 f7 02 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 23 ef 09 00 fb f4 <c3> cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
> RSP: 0018:ffffc9000013fe10 EFLAGS: 00000246
> RAX: 000000000004b053 RBX: ffff8881022d9e00 RCX: ffffffff877c9945
> RDX: 0000000000000000 RSI: ffffffff890f4061 RDI: ffffffff87b15700
> RBP: ffffed102045b3c0 R08: 0000000000000001 R09: ffffed103eae670d
> R10: ffff8881f573386b R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000000 R14: 1ffff92000027fc6 R15: dffffc0000000000
>   arch_safe_halt arch/x86/include/asm/paravirt.h:62 [inline]
>   default_idle+0x9/0x10 arch/x86/kernel/process.c:768
>   default_idle_call+0x6c/0xb0 kernel/sched/idle.c:122
>   cpuidle_idle_call kernel/sched/idle.c:199 [inline]
>   do_idle+0x3a7/0x5b0 kernel/sched/idle.c:355
>   cpu_startup_entry+0x4f/0x60 kernel/sched/idle.c:454
>   start_secondary+0x21d/0x2d0 arch/x86/kernel/smpboot.c:312
>   common_startup_64+0x13e/0x158
>   </TASK>
> 
> Allocated by task 23:
>   kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
>   kasan_save_track+0x14/0x30 mm/kasan/common.c:78
>   poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
>   __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:415
>   kasan_kmalloc include/linux/kasan.h:263 [inline]
>   __do_kmalloc_node mm/slub.c:5334 [inline]
>   __kmalloc_noprof+0x309/0x7c0 mm/slub.c:5359
>   _kmalloc_noprof include/linux/slab.h:992 [inline]
>   hcd_buffer_alloc+0x1f5/0x290 drivers/usb/core/buffer.c:134
>   usb_alloc_coherent+0x5f/0xa0 drivers/usb/core/usb.c:1011
>   hid_alloc_buffers drivers/hid/usbhid/hid-core.c:859 [inline]
>   usbhid_start+0x5cf/0x23a0 drivers/hid/usbhid/hid-core.c:1108
>   hid_hw_start+0x65/0x140 drivers/hid/hid-core.c:2428
>   aqc_probe+0x1a5/0x3510 drivers/hwmon/aquacomputer_d5next.c:1536
>   __hid_device_probe drivers/hid/hid-core.c:2829 [inline]
>   hid_device_probe+0x50e/0x800 drivers/hid/hid-core.c:2866
>   call_driver_probe drivers/base/dd.c:628 [inline]
>   really_probe+0x241/0xa60 drivers/base/dd.c:706
>   __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
>   driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
>   __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
>   bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
>   __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
>   device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
>   bus_probe_device+0x64/0x160 drivers/base/bus.c:620
>   device_add+0x121d/0x1970 drivers/base/core.c:3772
>   hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3010
>   usbhid_probe+0xa64/0x10b0 drivers/hid/usbhid/hid-core.c:1452
>   usb_probe_interface+0x386/0x9b0 drivers/usb/core/driver.c:399
>   call_driver_probe drivers/base/dd.c:628 [inline]
>   really_probe+0x241/0xa60 drivers/base/dd.c:706
>   __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
>   driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
>   __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
>   bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
>   __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
>   device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
>   bus_probe_device+0x64/0x160 drivers/base/bus.c:620
>   device_add+0x121d/0x1970 drivers/base/core.c:3772
>   usb_set_configuration+0xd97/0x1c60 drivers/usb/core/message.c:2268
>   usb_generic_driver_probe+0xa1/0xe0 drivers/usb/core/generic.c:250
>   usb_probe_device+0xef/0x400 drivers/usb/core/driver.c:293
>   call_driver_probe drivers/base/dd.c:628 [inline]
>   really_probe+0x241/0xa60 drivers/base/dd.c:706
>   __driver_probe_device+0x20e/0x450 drivers/base/dd.c:868
>   driver_probe_device+0x4a/0x140 drivers/base/dd.c:898
>   __device_attach_driver+0x1df/0x320 drivers/base/dd.c:1026
>   bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
>   __device_attach+0x1e4/0x4d0 drivers/base/dd.c:1098
>   device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1153
>   bus_probe_device+0x64/0x160 drivers/base/bus.c:620
>   device_add+0x121d/0x1970 drivers/base/core.c:3772
>   usb_new_device.part.0+0xcc2/0x1686 drivers/usb/core/hub.c:2708
>   usb_new_device drivers/usb/core/hub.c:5833 [inline]
>   hub_port_connect drivers/usb/core/hub.c:5580 [inline]
>   hub_port_connect_change drivers/usb/core/hub.c:5720 [inline]
>   port_event drivers/usb/core/hub.c:5884 [inline]
>   hub_event.cold+0x51a/0xe9d drivers/usb/core/hub.c:5966
>   process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
>   process_scheduled_works kernel/workqueue.c:3405 [inline]
>   worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
>   kthread+0x370/0x450 kernel/kthread.c:436
>   ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> 
> The buggy address belongs to the object at ffff888108aba200
>   which belongs to the cache kmalloc-96 of size 96
> The buggy address is located 22 bytes to the right of
>   allocated 65-byte region [ffff888108aba200, ffff888108aba241)
> 
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888108aba680 pfn:0x108aba
> flags: 0x200000000000200(workingset|node=0|zone=2)
> page_type: f5(slab)
> raw: 0200000000000200 ffff888100041280 ffff8881000401c8 ffffea00046bf250
> raw: ffff888108aba680 0000000800200017 00000000f5000000 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2c00(GFP_NOIO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 11, tgid 11 (kworker/0:1), ts 4259009323, free_ts 4258897945
>   set_page_owner include/linux/page_owner.h:32 [inline]
>   post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1859
>   prep_new_page mm/page_alloc.c:1867 [inline]
>   get_page_from_freelist+0xf25/0x3400 mm/page_alloc.c:3946
>   __alloc_frozen_pages_noprof+0x28f/0x2b90 mm/page_alloc.c:5304
>   alloc_slab_page mm/slub.c:3266 [inline]
>   allocate_slab mm/slub.c:3380 [inline]
>   new_slab+0xa2/0x670 mm/slub.c:3426
>   refill_objects+0xe3/0x410 mm/slub.c:7310
>   refill_sheaf mm/slub.c:2804 [inline]
>   __pcs_replace_empty_main+0x376/0x680 mm/slub.c:4675
>   alloc_from_pcs mm/slub.c:4773 [inline]
>   slab_alloc_node mm/slub.c:4905 [inline]
>   __kmalloc_cache_node_noprof+0x4b3/0x670 mm/slub.c:5504
>   _kmalloc_node_noprof include/linux/slab.h:1193 [inline]
>   __get_vm_area_node+0x101/0x330 mm/vmalloc.c:3237
>   __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4064
>   __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4165
>   __vmalloc_noprof+0xa3/0x120 mm/vmalloc.c:4181
>   pcpu_mem_zalloc+0x54/0xb0 mm/percpu.c:512
>   pcpu_alloc_chunk mm/percpu.c:1449 [inline]
>   pcpu_create_chunk+0x119/0x620 mm/percpu-vm.c:338
>   pcpu_balance_populated mm/percpu.c:2073 [inline]
>   pcpu_balance_workfn+0xb2c/0xdc0 mm/percpu.c:2215
>   process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
>   process_scheduled_works kernel/workqueue.c:3405 [inline]
>   worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
> page last free pid 11 tgid 11 stack trace:
>   reset_page_owner include/linux/page_owner.h:25 [inline]
>   __free_pages_prepare mm/page_alloc.c:1406 [inline]
>   __free_frozen_pages+0x716/0xf50 mm/page_alloc.c:2950
>   __kasan_populate_vmalloc_do mm/kasan/shadow.c:393 [inline]
>   __kasan_populate_vmalloc+0x1ea/0x210 mm/kasan/shadow.c:424
>   kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
>   alloc_vmap_area+0x95d/0x2bb0 mm/vmalloc.c:2145
>   __get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3248
>   __vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4064
>   __vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4165
>   __vmalloc_noprof+0xa3/0x120 mm/vmalloc.c:4181
>   pcpu_mem_zalloc+0x54/0xb0 mm/percpu.c:512
>   pcpu_alloc_chunk mm/percpu.c:1444 [inline]
>   pcpu_create_chunk+0xce/0x620 mm/percpu-vm.c:338
>   pcpu_balance_populated mm/percpu.c:2073 [inline]
>   pcpu_balance_workfn+0xb2c/0xdc0 mm/percpu.c:2215
>   process_one_work+0xa23/0x1940 kernel/workqueue.c:3322
>   process_scheduled_works kernel/workqueue.c:3405 [inline]
>   worker_thread+0x5ef/0xe50 kernel/workqueue.c:3486
>   kthread+0x370/0x450 kernel/kthread.c:436
>   ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> 
> Memory state around the buggy address:
>   ffff888108aba100: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
>   ffff888108aba180: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
>> ffff888108aba200: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
>                                                   ^
>   ffff888108aba280: 00 00 00 00 00 00 00 00 01 fc fc fc fc fc fc fc
>   ffff888108aba300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ==================================================================
> ----------------
> Code disassembly (best guess), 3 bytes skipped:
>     0:	e9 83 f7 02 00       	jmp    0x2f788
>     5:	0f 1f 00             	nopl   (%rax)
>     8:	90                   	nop
>     9:	90                   	nop
>     a:	90                   	nop
>     b:	90                   	nop
>     c:	90                   	nop
>     d:	90                   	nop
>     e:	90                   	nop
>     f:	90                   	nop
>    10:	90                   	nop
>    11:	90                   	nop
>    12:	90                   	nop
>    13:	90                   	nop
>    14:	90                   	nop
>    15:	90                   	nop
>    16:	90                   	nop
>    17:	90                   	nop
>    18:	f3 0f 1e fa          	endbr64
>    1c:	66 90                	xchg   %ax,%ax
>    1e:	0f 00 2d 23 ef 09 00 	verw   0x9ef23(%rip)        # 0x9ef48
>    25:	fb                   	sti
>    26:	f4                   	hlt
> * 27:	c3                   	ret <-- trapping instruction
>    28:	cc                   	int3
>    29:	cc                   	int3
>    2a:	cc                   	int3
>    2b:	cc                   	int3
>    2c:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
>    33:	00 00 00
>    36:	66 90                	xchg   %ax,%ax
>    38:	90                   	nop
>    39:	90                   	nop
>    3a:	90                   	nop
>    3b:	90                   	nop
>    3c:	90                   	nop
> 
> 
> ---
> 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
> 

Re: [syzbot] [hwmon?] KASAN: slab-out-of-bounds Read in aqc_raw_event

[Aleksa Savic]

On 8/22/26 6:02 AM, Guenter Roeck wrote:
> Aleksa,
> 
> On 8/21/26 20:06, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    e1e6e541c5c9 Merge tag 'thunderbolt-for-v7.3-rc1' of 
>> ssh:/..
>> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/ 
>> gregkh/usb.git usb-testing
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16086e79580000
>> kernel config:  https://syzkaller.appspot.com/x/.config? 
>> x=8bdeea7ee6735f91
>> dashboard link: https://syzkaller.appspot.com/bug? 
>> extid=9ee5f5dc18673d6b2f37
>> 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=14737679580000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15a22549580000
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/3b0a1f8e6a1f/ 
>> disk-e1e6e541.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/f98d855e85e8/ 
>> vmlinux-e1e6e541.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/ 
>> db2c3a41df6d/bzImage-e1e6e541.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the 
>> commit:
>> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
>>
>> ==================================================================
>> BUG: KASAN: slab-out-of-bounds in get_unaligned_be16 include/linux/ 
>> unaligned.h:48 [inline]
>> BUG: KASAN: slab-out-of-bounds in aqc_raw_event drivers/hwmon/ 
>> aquacomputer_d5next.c:1345 [inline]
>> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/ 
>> hwmon/aquacomputer_d5next.c:1327
> 
> The problem is that syzkaller sends a bad (short) report.
> aqc_raw_event() needs to validate the report size and bail out
> if it is short. The fix should be straightforard if it is known
> what the minimum report size is. D5NEXT_CTRL_REPORT_SIZE ?
> 
> Thanks,
> Guenter

We do know sizes of control (setting) reports since we send them through 
priv->buffer, but aqc_raw_event() gets sensor reports and their length 
can vary per device. I don't have an exact list for all devices since I 
don't have them all myself. We'll need to verify that what we receive in 
aqc_raw_event() is >= the minimum offset we want to read sensor values from.

Thanks,
Aleksa

Re: [syzbot] [hwmon?] KASAN: slab-out-of-bounds Read in aqc_raw_event

[Guenter Roeck]

On 8/22/26 01:07, Aleksa Savic wrote:
> On 8/22/26 6:02 AM, Guenter Roeck wrote:
>> Aleksa,
>>
>> On 8/21/26 20:06, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:    e1e6e541c5c9 Merge tag 'thunderbolt-for-v7.3-rc1' of ssh:/..
>>> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/ gregkh/usb.git usb-testing
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=16086e79580000
>>> kernel config:  https://syzkaller.appspot.com/x/.config? x=8bdeea7ee6735f91
>>> dashboard link: https://syzkaller.appspot.com/bug? extid=9ee5f5dc18673d6b2f37
>>> 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=14737679580000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15a22549580000
>>>
>>> Downloadable assets:
>>> disk image: https://storage.googleapis.com/syzbot-assets/3b0a1f8e6a1f/ disk-e1e6e541.raw.xz
>>> vmlinux: https://storage.googleapis.com/syzbot-assets/f98d855e85e8/ vmlinux-e1e6e541.xz
>>> kernel image: https://storage.googleapis.com/syzbot-assets/ db2c3a41df6d/bzImage-e1e6e541.xz
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
>>>
>>> ==================================================================
>>> BUG: KASAN: slab-out-of-bounds in get_unaligned_be16 include/linux/ unaligned.h:48 [inline]
>>> BUG: KASAN: slab-out-of-bounds in aqc_raw_event drivers/hwmon/ aquacomputer_d5next.c:1345 [inline]
>>> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/ hwmon/aquacomputer_d5next.c:1327
>>
>> The problem is that syzkaller sends a bad (short) report.
>> aqc_raw_event() needs to validate the report size and bail out
>> if it is short. The fix should be straightforard if it is known
>> what the minimum report size is. D5NEXT_CTRL_REPORT_SIZE ?
>>
>> Thanks,
>> Guenter
> 
> We do know sizes of control (setting) reports since we send them through priv->buffer, but aqc_raw_event() gets sensor reports and their length can vary per device. I don't have an exact list for all devices since I don't have them all myself. We'll need to verify that what we receive in aqc_raw_event() is >= the minimum offset we want to read sensor values from.

Agreed. We'll need something like min_raw_report_size per device.
It doesn't have to be accurate, just large enough to cover all values
that are extracted from the report. I think for D5 that would be
110 (D5NEXT_PUMP_OFFSET + 3), but I may have miscalculated it.

Thanks,
Guenter

[PATCH] hwmon: valid the data size before reading the sensor data

[Edward Adam Davis]

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is smaller than the buffer
size when reading the data, resulting in [1] during the read process.

Add a check for the data size, if it less than the buffer size, the sensor
data read is aborted.

[1]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0
Call Trace:
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 drivers/hwmon/aquacomputer_d5next.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index 1ca70e726298..1cc6c220ffe9 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1334,6 +1334,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
 
 	priv = hid_get_drvdata(hdev);
 
+	if (size < priv->buffer_size)
+		return 0;
+
 	/* Info provided with every report */
 	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
 	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +
-- 
2.43.0

Re: [PATCH] hwmon: valid the data size before reading the sensor data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The patch introduces a regression that breaks sensor updates for multiple legitimate devices by incorrectly validating the status report size against the control report size.

Pre-existing issues:
- [High] The patch fails to prevent out-of-bounds reads for several devices because their `buffer_size` is never initialized, leaving the vulnerability completely unfixed.
--

--- Patch [1]: [PATCH] hwmon: valid the data size before reading the sensor data ---
commit 551cce5fc615bfa2ca7512a6e77f7f9ea4f91fc7
Author: Edward Adam Davis <eadavis@qq.com>

hwmon: valid the data size before reading the sensor data

This patch adds a size check in aqc_raw_event() to abort reading if the
sensor data size is smaller than the expected buffer size. This aims to
prevent a KASAN out-of-bounds read when processing maliciously short
user-forged sensor data.

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>

> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e7262988..1cc6c220ffe96 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
> @@ -1334,6 +1334,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
>  
>  	priv = hid_get_drvdata(hdev);
>  
> +	if (size < priv->buffer_size)
> +		return 0;
> +

[Severity: High]
Will this check inadvertently drop legitimate hardware sensor updates for
devices like d5next or aquaero?

The incoming asynchronous input status report size is being compared against
priv->buffer_size, which stores the size of the device's control feature
report. For non-legacy devices, priv->buffer_size is initialized during probe
to large values (e.g., 809 bytes for d5next and 2707 bytes for aquaero), while
valid status input reports are significantly smaller.

Since the legitimate status report size naturally falls short of the control
report size, won't this cause the driver to silently discard all valid sensor
updates for these devices?

[Severity: High]
This is a pre-existing issue, but does this check fail to prevent the
out-of-bounds read for several devices where priv->buffer_size is 0?

The aqc_data struct is allocated with devm_kzalloc(), meaning
priv->buffer_size defaults to 0. While devices like d5next initialize this
field, it is intentionally left unassigned (and thus 0) for devices like
leakshield, highflownext, aquastreamult, and farbwerk:

drivers/hwmon/aquacomputer_d5next.c:aqc_probe() {
    ...
	case USB_PRODUCT_ID_HIGHFLOWNEXT:
		priv->kind = highflownext;
		priv->num_fans = 0;
		priv->num_temp_sensors = HIGHFLOWNEXT_NUM_SENSORS;
    ...
}

When a maliciously small report is received for one of these devices, the
check evaluates to size < 0, which is always false. Doesn't this bypass the
validation entirely, allowing the driver to read from hardcoded offsets well
past the end of the short report?

>  	/* Info provided with every report */
>  	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
>  	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_8FCF9A8DDF25A10DCC12265DF45DBE995307@qq.com?part=1

[PATCH v2] hwmon: valid the data size before reading the sensor data

[Edward Adam Davis]

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item to be read, abort the sensor data read operation.

[1]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0
Call Trace:
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: change to check the data item and update comments

 drivers/hwmon/aquacomputer_d5next.c | 73 +++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index 1ca70e726298..c6fe36abfe56 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1324,6 +1324,76 @@ static const struct hwmon_chip_info aqc_chip_info = {
 	.info = aqc_info,
 };
 
+static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
+{
+	int off;
+	char *msg;
+
+	if (!priv)
+		return false;
+
+	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET;
+	if (off >= size) {
+		msg = "serial number start offset";
+		goto invalid;
+	}
+
+	off = priv->firmware_version_offset;
+	if (off >= size) {
+		msg = "firmware version offset";
+		goto invalid;
+	}
+
+	/* Physical temperature sensor readings data size check*/
+	if (priv->num_temp_sensors > 0) {
+		off = priv->temp_sensor_start_offset +
+		      (priv->num_temp_sensors - 1) * AQC_SENSOR_SIZE;
+
+		if (off >= size) {
+			msg = "temp sensor start offset";
+			goto invalid;
+		}
+	}
+	/* Virtual temperature sensor readings data size check*/
+	if (priv->num_virtual_temp_sensors > 0) {
+		off = priv->virtual_temp_sensor_start_offset +
+		      (priv->num_virtual_temp_sensors - 1) * AQC_SENSOR_SIZE;
+
+		if (off >= size) {
+			msg = "virtual temp sensor start offset";
+			goto invalid;
+		}
+	}
+	/* Fan speed and related readings data size check */
+	if (priv->num_fans > 0) {
+		int fan_off = priv->fan_sensor_offsets[priv->num_fans - 1];
+
+		off = fan_off + priv->fan_structure->power;
+		if (off >= size) {
+			msg = "fan power offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->voltage;
+		if (off >= size) {
+			msg = "fan voltage offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->curr;
+		if (off >= size) {
+			msg = "fan curr offset";
+			goto invalid;
+		}
+	}
+
+	return true;
+invalid:
+	pr_debug("data size (%d) is less than the %s, %s\n",
+		 size, msg, __func__);
+	return false;
+}
+
 static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data, int size)
 {
 	int i, j, sensor_value;
@@ -1334,6 +1404,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
 
 	priv = hid_get_drvdata(hdev);
 
+	if (!aqc_raw_data_valid(priv, size))
+		return 0;
+
 	/* Info provided with every report */
 	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
 	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +
-- 
2.43.0

Re: [PATCH v2] hwmon: valid the data size before reading the sensor data

[Guenter Roeck]

On 8/22/26 00:45, Edward Adam Davis wrote:
> The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> fails to handle cases where the sensor data length is too small when reading
> the data, resulting in [1] during the read process.
> 
> Add a data size check, if the size is less than that required for the
> specific data item to be read, abort the sensor data read operation.
> 
> [1]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> Call Trace:
>   get_unaligned_be16 include/linux/unaligned.h:48 [inline]
>   aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
>   aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
>   __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
>   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
> 
> Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> v1 -> v2: change to check the data item and update comments

Please stop sending me AI generated patches. Whatever model you are using
has no clue what it is doing.

Guenter

Re: [PATCH v2] hwmon: valid the data size before reading the sensor data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The bounds checking logic in `aqc_raw_data_valid` uses an incorrect comparison, resulting in off-by-one errors that allow 1-byte out-of-bounds reads.
- [High] `aqc_raw_data_valid` incorrectly assumes `fan_sensor_offsets` is sorted in ascending order, failing to validate larger offsets at lower array indices.

Pre-existing issues:
- [High] `aqc_raw_data_valid` completely omits bounds checks for several offsets that are subsequently read in `aqc_raw_event`, leaving the driver vulnerable to out-of-bounds reads.
- [High] Processing a crafted report for legacy devices like `aquastreamxt` triggers a NULL pointer dereference on `priv->fan_structure`.
--

--- Patch [1]: [PATCH v2] hwmon: valid the data size before reading the sensor data ---
commit a13b90e2804a6e0d888f292535c33b47d5d8f7fb
Author: Edward Adam Davis <eadavis@qq.com>

hwmon: valid the data size before reading the sensor data

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item to be read, abort the sensor data read operation.

Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com

> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e7262988..c6fe36abfe569 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c

[ ... ]

> @@ -1324,6 +1324,76 @@ static const struct hwmon_chip_info aqc_chip_info = {
>  	.info = aqc_info,
>  };
>  
> +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> +{
> +	int off;
> +	char *msg;
> +
> +	if (!priv)
> +		return false;
> +
> +	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET;
> +	if (off >= size) {

[Severity: High]
Does this bounds check adequately protect against multi-byte reads?

The condition if (off >= size) evaluates to false when size == off + 1.
However, aqc_raw_event() uses get_unaligned_be16(), which reads 2 bytes.

If the device sends a report with a size exactly equal to off + 1, won't
reading 2 bytes at offset size - 1 access one byte beyond the buffer?

[ ... ]

> +	/* Fan speed and related readings data size check */
> +	if (priv->num_fans > 0) {
> +		int fan_off = priv->fan_sensor_offsets[priv->num_fans - 1];

[Severity: High]
Does this code assume that the fan_sensor_offsets array is always sorted in
ascending order?

For devices like d5next, the array is initialized as:
{ D5NEXT_PUMP_OFFSET (108), D5NEXT_FAN_OFFSET (95) }

The check uses the last index (95) for bounds validation. This would pass a
report of size 104, but aqc_raw_event() will subsequently access index 0
(108), resulting in an out-of-bounds read.

> +
> +		off = fan_off + priv->fan_structure->power;

[Severity: High]
This isn't a bug introduced by this patch, but can priv->fan_structure be
NULL here?

For legacy devices like aquastreamxt, priv->num_fans is set to 2 during
probe, but priv->fan_structure is never assigned and remains NULL. While
this NULL dereference already existed in aqc_raw_event(), this patch adds
another immediate dereference here.

> +		if (off >= size) {
> +			msg = "fan power offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->voltage;
> +		if (off >= size) {
> +			msg = "fan voltage offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->curr;
> +		if (off >= size) {

[Severity: High]
This is a pre-existing issue, but does this adequately cover all fields
accessed in aqc_raw_event()?

This validation omits checks for several offsets, such as:
- priv->fan_structure->speed
- priv->flow_sensors_start_offset
- priv->power_cycle_count_offset
- Device-specific offsets inside the switch (priv->kind) block (e.g.,
  HIGHFLOWNEXT_POWER).

Since aqc_raw_event() unconditionally reads these fields, an out-of-bounds
read could still occur for truncated reports.

> +			msg = "fan curr offset";
> +			goto invalid;
> +		}
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_D74E75F577C166FC3CBB36B6966836D44A09@qq.com?part=1

[PATCH v3] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Edward Adam Davis]

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item to be read, abort the sensor data read operation.

[1]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0
Call Trace:
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: change to check the data item and update comments
v2 -> v3: check all sub items and update subject

 drivers/hwmon/aquacomputer_d5next.c | 74 +++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index 1ca70e726298..2381a74eb4a4 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1324,6 +1324,77 @@ static const struct hwmon_chip_info aqc_chip_info = {
 	.info = aqc_info,
 };
 
+static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
+{
+	int off, fan_off, i;
+	char *msg;
+
+	if (!priv)
+		return false;
+
+	/* +1 for get_unaligned_be16(), it reads 2 bytes */
+	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
+	if (off >= size) {
+		msg = "serial number start offset";
+		goto invalid;
+	}
+
+	off = priv->firmware_version_offset + 1;
+	if (off >= size) {
+		msg = "firmware version offset";
+		goto invalid;
+	}
+
+	/* Physical temperature sensor readings data size check*/
+	for (i = 0; i < priv->num_temp_sensors; i++) {
+		off = priv->temp_sensor_start_offset + i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size) {
+			msg = "temp sensor start offset";
+			goto invalid;
+		}
+	}
+
+	/* Virtual temperature sensor readings data size check*/
+	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
+		off = priv->virtual_temp_sensor_start_offset +
+		      i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size) {
+			msg = "virtual temp sensor start offset";
+			goto invalid;
+		}
+	}
+
+	/* Fan speed and related readings data size check */
+	for (i = 0; i < priv->num_fans; i++) {
+		fan_off = priv->fan_sensor_offsets[i] + 1;
+		off = fan_off + priv->fan_structure->power;
+		if (off >= size) {
+			msg = "fan power offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->voltage;
+		if (off >= size) {
+			msg = "fan voltage offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->curr;
+		if (off >= size) {
+			msg = "fan curr offset";
+			goto invalid;
+		}
+	}
+
+	return true;
+invalid:
+	pr_debug("data size (%d) is less than the %s, %s\n",
+		 size, msg, __func__);
+	return false;
+}
+
 static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data, int size)
 {
 	int i, j, sensor_value;
@@ -1334,6 +1405,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
 
 	priv = hid_get_drvdata(hdev);
 
+	if (!aqc_raw_data_valid(priv, size))
+		return 0;
+
 	/* Info provided with every report */
 	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
 	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +
-- 
2.43.0

Re: [PATCH v3] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The newly added validation function `aqc_raw_data_valid` is incomplete and leaves multiple out-of-bounds reads unhandled.
- [High] NULL pointer dereference when a malicious USB device spoofing an `aquastreamxt` device sends a STATUS_REPORT_ID (0x01) input report.
--

--- Patch [1]: [PATCH v3] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data ---
commit f2f8bc6cd48d08e98637bc3e14b8b66f1ed8bcd4
Author: Edward Adam Davis <eadavis@qq.com>
Subject: hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

This commit adds a data size check function, aqc_raw_data_valid(), to prevent
out-of-bounds reads when a device sends a truncated HID report. It aborts the
sensor data read operation if the received data size is smaller than required.

Link: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37

> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e7262988..2381a74eb4a48 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
[ ... ]
> +	/* Fan speed and related readings data size check */
> +	for (i = 0; i < priv->num_fans; i++) {
> +		fan_off = priv->fan_sensor_offsets[i] + 1;
> +		off = fan_off + priv->fan_structure->power;

[Severity: High]
This is a pre-existing issue, but does this code lead to a NULL pointer
dereference for aquastreamxt devices?

For legacy aquastreamxt devices, priv->num_fans is initialized to 2,
but priv->fan_structure is left unassigned (NULL). Legacy devices
normally communicate using report ID 0x04. If a malicious USB device
spoofs an aquastreamxt device and sends a report with
STATUS_REPORT_ID (0x01), would aqc_raw_data_valid() and
aqc_raw_event() blindly dereference priv->fan_structure->power?

Additionally, while this patch attempts to fix the out-of-bounds
reads, are we missing bounds checking for priv->fan_structure->speed
here?

The speed attribute often has the largest offset
(e.g., AQC_FAN_SPEED_OFFSET is 0x08, while power is 0x06). Could a
truncated report still cause an out-of-bounds read when accessing
the speed offset later in aqc_raw_event()?

> +		if (off >= size) {
> +			msg = "fan power offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->voltage;
> +		if (off >= size) {
> +			msg = "fan voltage offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->curr;
> +		if (off >= size) {
> +			msg = "fan curr offset";
> +			goto invalid;
> +		}
> +	}
> +

[Severity: High]
This is a pre-existing issue, but does this function leave several
out-of-bounds reads unprotected?

The new aqc_raw_data_valid() function skips checking
priv->flow_sensors_start_offset, priv->power_cycle_count_offset, and
device-specific sensors (like LEAKSHIELD_RESERVOIR_VOLUME). If a
malicious USB device sends a short HID report with STATUS_REPORT_ID,
could these reads still trigger a slab-out-of-bounds access inside
aqc_raw_event()?

> +	return true;
> +invalid:
> +	pr_debug("data size (%d) is less than the %s, %s\n",
> +		 size, msg, __func__);
> +	return false;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_54372C4A0A752D77EF66BC3CA9377097F009@qq.com?part=1

[PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Edward Adam Davis]

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item to be read, abort the sensor data read operation.

[1]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0
Call Trace:
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: change to check the data item and update comments
v2 -> v3: check all sub items and update subject
v3 -> v4: add speed and flow check

 drivers/hwmon/aquacomputer_d5next.c | 104 ++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index 1ca70e726298..89c9fc0c77e5 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1324,6 +1324,107 @@ static const struct hwmon_chip_info aqc_chip_info = {
 	.info = aqc_info,
 };
 
+/* aqc_raw_data_valid()
+ * Does not support special-case sensor readings data size check
+ */
+static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
+{
+	int off, fan_off, i;
+	char *msg;
+
+	if (!priv)
+		return false;
+
+	/* +1 for get_unaligned_be16(), it reads 2 bytes */
+	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
+	if (off >= size) {
+		msg = "serial number start offset";
+		goto invalid;
+	}
+
+	off = priv->firmware_version_offset + 1;
+	if (off >= size) {
+		msg = "firmware version offset";
+		goto invalid;
+	}
+
+	/* Physical temperature sensor readings data size check*/
+	for (i = 0; i < priv->num_temp_sensors; i++) {
+		off = priv->temp_sensor_start_offset + i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size) {
+			msg = "temp sensor start offset";
+			goto invalid;
+		}
+	}
+
+	/* Virtual temperature sensor readings data size check*/
+	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
+		off = priv->virtual_temp_sensor_start_offset +
+		      i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size) {
+			msg = "virtual temp sensor start offset";
+			goto invalid;
+		}
+	}
+
+	/* Fan speed and related readings data size check */
+	if (!priv->fan_structure)
+		goto flow;
+
+	for (i = 0; i < priv->num_fans; i++) {
+		fan_off = priv->fan_sensor_offsets[i] + 1;
+		off = fan_off + priv->fan_structure->speed;
+		if (off >= size) {
+			msg = "fan speed offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->power;
+		if (off >= size) {
+			msg = "fan power offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->voltage;
+		if (off >= size) {
+			msg = "fan voltage offset";
+			goto invalid;
+		}
+
+		off = fan_off + priv->fan_structure->curr;
+		if (off >= size) {
+			msg = "fan curr offset";
+			goto invalid;
+		}
+	}
+
+flow:
+	/* Flow sensor readings data size check */
+	for (i = 0; i < priv->num_flow_sensors; i++) {
+		off = priv->flow_sensors_start_offset + i * AQC_SENSOR_SIZE + 1;
+		if (off >= size) {
+			msg = "flow sensors start offset";
+			goto invalid;
+		}
+	}
+
+	if (priv->power_cycle_count_offset != 0) {
+		off = priv->power_cycle_count_offset + 3;
+		if (off >= size) {
+			msg = "power cycle count offset";
+			goto invalid;
+		}
+	}
+
+	return true;
+invalid:
+	pr_debug("data size (%d) is less than the %s, %s\n",
+		 size, msg, __func__);
+	return false;
+}
+
 static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data, int size)
 {
 	int i, j, sensor_value;
@@ -1334,6 +1435,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
 
 	priv = hid_get_drvdata(hdev);
 
+	if (!aqc_raw_data_valid(priv, size))
+		return 0;
+
 	/* Info provided with every report */
 	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
 	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +
-- 
2.43.0

Re: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch's attempt to fix the out-of-bounds read is incomplete. The newly added `aqc_raw_data_valid()` deliberately skips bounds checking for special-case sensors (like `leakshield`, `aquastreamult`, and `highflownext`). An attacker can supply a HID report that passes the initial generic length checks, but is too small for the special-case offsets (e.g., `LEAKSHIELD_PRESSURE_ADJUSTED` at offset 285). The switch statement in `aqc_raw_event()` then unconditionally reads these out-of-bounds offsets.
- [High] This problem wasn't introduced by this patch, but a malicious HID device mimicking `aquastreamxt` can trigger a NULL pointer dereference in `aqc_raw_event()`. For `aquastreamxt`, `priv->fan_structure` is deliberately left uninitialized (NULL) during `probe()`. The patch author added `if (!priv->fan_structure) goto flow;` in `aqc_raw_data_valid()` to skip checking it, but missed that the loop in `aqc_raw_event()` will still execute because `priv->num_fans` is 2. The loop unconditionally dereferences `priv->fan_structure->speed`, causing an immediate kernel panic.
- [High] This problem wasn't introduced by this patch, but there is a missing bounds check on `hdev->maxcollection` before accessing `hdev->collection[1]` in `aqc_probe()`. A malicious USB device can present a HID report descriptor that defines 0 or 1 collections, leading to an out-of-bounds array read when the driver checks `hdev->collection[1].type`.
--

--- Patch [1]: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data ---
commit 78df709d4519cd7ca51246e494c81774b1f7c3ae
Author: Edward Adam Davis <eadavis@qq.com>

hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item to be read, abort the sensor data read operation.

Link: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37

> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e7262988..89c9fc0c77e52 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
> @@ -1324,6 +1324,107 @@ static const struct hwmon_chip_info aqc_chip_info = {
>  	.info = aqc_info,
>  };
>  
> +/* aqc_raw_data_valid()
> + * Does not support special-case sensor readings data size check
> + */

[Severity: High]
This problem wasn't introduced by this patch, but the patch's attempt to fix
the out-of-bounds read seems incomplete. The newly added aqc_raw_data_valid()
deliberately skips bounds checking for special-case sensors (like leakshield,
aquastreamult, and highflownext).

Could an attacker supply a HID report that passes the initial generic length
checks, but is too small for the special-case offsets?

For example, LEAKSHIELD_PRESSURE_ADJUSTED is at offset 285. The switch
statement in aqc_raw_event() then unconditionally reads these out-of-bounds
offsets:

	case leakshield:
		priv->speed_input[0] =
		    ((s16)get_unaligned_be16(data + LEAKSHIELD_PRESSURE_ADJUSTED)) * 100;

> +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> +{
[ ... ]
> +	/* Fan speed and related readings data size check */
> +	if (!priv->fan_structure)
> +		goto flow;

[Severity: High]
This isn't a bug introduced by this patch, but could this cause a NULL pointer
dereference?

For aquastreamxt, priv->fan_structure is deliberately left uninitialized
(NULL) during probe(). The check above skips bounds checking when
fan_structure is NULL, but misses that the loop in aqc_raw_event() will still
execute because priv->num_fans is 2.

The loop in aqc_raw_event() unconditionally dereferences priv->fan_structure:

	for (i = 0; i < priv->num_fans; i++) {
		priv->speed_input[i] =
		    get_unaligned_be16(data + priv->fan_sensor_offsets[i] +
				       priv->fan_structure->speed);

Could a malicious HID device mimicking aquastreamxt trigger a kernel panic
here?

[ ... ]

[Severity: High]
This is a pre-existing issue, but is there a missing bounds check on
hdev->maxcollection before accessing hdev->collection[1] in aqc_probe()?

If a malicious USB device presents a HID report descriptor that defines 0 or 1
collections, could the driver perform an out-of-bounds array read when it
checks hdev->collection[1].type:

drivers/hwmon/aquacomputer_d5next.c:aqc_probe() {
	...
	if (hdev->collection[1].type != 0) {
		ret = -ENODEV;
		goto fail_and_close;
	}
	...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_CE16CF998D9A25B20DEF1275DDCEDDB61907@qq.com?part=1

Re: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Greg KH]

On Sat, Aug 22, 2026 at 07:34:35PM +0800, Edward Adam Davis wrote:
> The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> fails to handle cases where the sensor data length is too small when reading
> the data, resulting in [1] during the read process.

What is "user-forged sensor data"?

> 
> Add a data size check, if the size is less than that required for the
> specific data item to be read, abort the sensor data read operation.

This patch does much more than that.

> 
> [1]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> Call Trace:
>  get_unaligned_be16 include/linux/unaligned.h:48 [inline]
>  aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
>  aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
>  __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
>  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
> 
> Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---

Was the Assisted-by: tag forgotten?


> v1 -> v2: change to check the data item and update comments
> v2 -> v3: check all sub items and update subject
> v3 -> v4: add speed and flow check
> 
>  drivers/hwmon/aquacomputer_d5next.c | 104 ++++++++++++++++++++++++++++
>  1 file changed, 104 insertions(+)
> 
> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e726298..89c9fc0c77e5 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
> @@ -1324,6 +1324,107 @@ static const struct hwmon_chip_info aqc_chip_info = {
>  	.info = aqc_info,
>  };
>  
> +/* aqc_raw_data_valid()
> + * Does not support special-case sensor readings data size check

Why not?

> + */
> +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> +{
> +	int off, fan_off, i;
> +	char *msg;
> +
> +	if (!priv)
> +		return false;
> +
> +	/* +1 for get_unaligned_be16(), it reads 2 bytes */
> +	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
> +	if (off >= size) {
> +		msg = "serial number start offset";

That's a lot of debugging code being added, why?  Who is going to use
that?



> +		goto invalid;
> +	}
> +
> +	off = priv->firmware_version_offset + 1;
> +	if (off >= size) {
> +		msg = "firmware version offset";
> +		goto invalid;
> +	}
> +
> +	/* Physical temperature sensor readings data size check*/
> +	for (i = 0; i < priv->num_temp_sensors; i++) {
> +		off = priv->temp_sensor_start_offset + i * AQC_SENSOR_SIZE + 1;
> +
> +		if (off >= size) {
> +			msg = "temp sensor start offset";
> +			goto invalid;
> +		}
> +	}
> +
> +	/* Virtual temperature sensor readings data size check*/
> +	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
> +		off = priv->virtual_temp_sensor_start_offset +
> +		      i * AQC_SENSOR_SIZE + 1;
> +
> +		if (off >= size) {
> +			msg = "virtual temp sensor start offset";
> +			goto invalid;
> +		}
> +	}
> +
> +	/* Fan speed and related readings data size check */
> +	if (!priv->fan_structure)
> +		goto flow;
> +
> +	for (i = 0; i < priv->num_fans; i++) {
> +		fan_off = priv->fan_sensor_offsets[i] + 1;
> +		off = fan_off + priv->fan_structure->speed;
> +		if (off >= size) {
> +			msg = "fan speed offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->power;
> +		if (off >= size) {
> +			msg = "fan power offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->voltage;
> +		if (off >= size) {
> +			msg = "fan voltage offset";
> +			goto invalid;
> +		}
> +
> +		off = fan_off + priv->fan_structure->curr;
> +		if (off >= size) {
> +			msg = "fan curr offset";
> +			goto invalid;
> +		}
> +	}
> +
> +flow:
> +	/* Flow sensor readings data size check */
> +	for (i = 0; i < priv->num_flow_sensors; i++) {
> +		off = priv->flow_sensors_start_offset + i * AQC_SENSOR_SIZE + 1;
> +		if (off >= size) {
> +			msg = "flow sensors start offset";
> +			goto invalid;
> +		}
> +	}
> +
> +	if (priv->power_cycle_count_offset != 0) {
> +		off = priv->power_cycle_count_offset + 3;
> +		if (off >= size) {
> +			msg = "power cycle count offset";
> +			goto invalid;
> +		}
> +	}
> +
> +	return true;
> +invalid:
> +	pr_debug("data size (%d) is less than the %s, %s\n",
> +		 size, msg, __func__);

drivers should always use dev_dbg().

also pr_debug() already has __func__ in it.  Please fix your LLM.

thanks,

greg k-h

Re: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Edward Adam Davis]

On Sat, 22 Aug 2026 13:55:35 +0200, Greg KH wrote:
> On Sat, Aug 22, 2026 at 07:34:35PM +0800, Edward Adam Davis wrote:
> > The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> > fails to handle cases where the sensor data length is too small when reading
> > the data, resulting in [1] during the read process.
> 
> What is "user-forged sensor data"?
It is the data constructed within the reproducer.
> 
> > 
> > Add a data size check, if the size is less than that required for the
> > specific data item to be read, abort the sensor data read operation.
> 
> This patch does much more than that.
Got it, I will write more comments.
> 
> > 
> > [1]
> > BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> > Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> > Call Trace:
> >  get_unaligned_be16 include/linux/unaligned.h:48 [inline]
> >  aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
> >  aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> >  __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
> >  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
> > 
> > Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> > Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> > Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> 
> Was the Assisted-by: tag forgotten?
No one has assisted me so far; also, I haven't used this type of tag before.
> 
> 
> > v1 -> v2: change to check the data item and update comments
> > v2 -> v3: check all sub items and update subject
> > v3 -> v4: add speed and flow check
> > 
> >  drivers/hwmon/aquacomputer_d5next.c | 104 ++++++++++++++++++++++++++++
> >  1 file changed, 104 insertions(+)
> > 
> > diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> > index 1ca70e726298..89c9fc0c77e5 100644
> > --- a/drivers/hwmon/aquacomputer_d5next.c
> > +++ b/drivers/hwmon/aquacomputer_d5next.c
> > @@ -1324,6 +1324,107 @@ static const struct hwmon_chip_info aqc_chip_info = {
> >  	.info = aqc_info,
> >  };
> >  
> > +/* aqc_raw_data_valid()
> > + * Does not support special-case sensor readings data size check
> 
> Why not?
It would be more appropriate for the maintainers of these sensors to add
the relevant checks.
> 
> > + */
> > +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> > +{
> > +	int off, fan_off, i;
> > +	char *msg;
> > +
> > +	if (!priv)
> > +		return false;
> > +
> > +	/* +1 for get_unaligned_be16(), it reads 2 bytes */
> > +	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
> > +	if (off >= size) {
> > +		msg = "serial number start offset";
> 
> That's a lot of debugging code being added, why?  Who is going to use
> that?
I am not certain that these debug messages are definitely useful;
I simply included them because I felt they might be helpful.
> 
> 
> 
> > +		goto invalid;
> > +	}
> > +
> > +	off = priv->firmware_version_offset + 1;
> > +	if (off >= size) {
> > +		msg = "firmware version offset";
> > +		goto invalid;
> > +	}
> > +
> > +	/* Physical temperature sensor readings data size check*/
> > +	for (i = 0; i < priv->num_temp_sensors; i++) {
> > +		off = priv->temp_sensor_start_offset + i * AQC_SENSOR_SIZE + 1;
> > +
> > +		if (off >= size) {
> > +			msg = "temp sensor start offset";
> > +			goto invalid;
> > +		}
> > +	}
> > +
> > +	/* Virtual temperature sensor readings data size check*/
> > +	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
> > +		off = priv->virtual_temp_sensor_start_offset +
> > +		      i * AQC_SENSOR_SIZE + 1;
> > +
> > +		if (off >= size) {
> > +			msg = "virtual temp sensor start offset";
> > +			goto invalid;
> > +		}
> > +	}
> > +
> > +	/* Fan speed and related readings data size check */
> > +	if (!priv->fan_structure)
> > +		goto flow;
> > +
> > +	for (i = 0; i < priv->num_fans; i++) {
> > +		fan_off = priv->fan_sensor_offsets[i] + 1;
> > +		off = fan_off + priv->fan_structure->speed;
> > +		if (off >= size) {
> > +			msg = "fan speed offset";
> > +			goto invalid;
> > +		}
> > +
> > +		off = fan_off + priv->fan_structure->power;
> > +		if (off >= size) {
> > +			msg = "fan power offset";
> > +			goto invalid;
> > +		}
> > +
> > +		off = fan_off + priv->fan_structure->voltage;
> > +		if (off >= size) {
> > +			msg = "fan voltage offset";
> > +			goto invalid;
> > +		}
> > +
> > +		off = fan_off + priv->fan_structure->curr;
> > +		if (off >= size) {
> > +			msg = "fan curr offset";
> > +			goto invalid;
> > +		}
> > +	}
> > +
> > +flow:
> > +	/* Flow sensor readings data size check */
> > +	for (i = 0; i < priv->num_flow_sensors; i++) {
> > +		off = priv->flow_sensors_start_offset + i * AQC_SENSOR_SIZE + 1;
> > +		if (off >= size) {
> > +			msg = "flow sensors start offset";
> > +			goto invalid;
> > +		}
> > +	}
> > +
> > +	if (priv->power_cycle_count_offset != 0) {
> > +		off = priv->power_cycle_count_offset + 3;
> > +		if (off >= size) {
> > +			msg = "power cycle count offset";
> > +			goto invalid;
> > +		}
> > +	}
> > +
> > +	return true;
> > +invalid:
> > +	pr_debug("data size (%d) is less than the %s, %s\n",
> > +		 size, msg, __func__);
> 
> drivers should always use dev_dbg().
> 
> also pr_debug() already has __func__ in it.  Please fix your LLM.
Got it.

BR,
Edward

Re: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Greg KH]

On Sat, Aug 22, 2026 at 08:23:35PM +0800, Edward Adam Davis wrote:
> On Sat, 22 Aug 2026 13:55:35 +0200, Greg KH wrote:
> > On Sat, Aug 22, 2026 at 07:34:35PM +0800, Edward Adam Davis wrote:
> > > The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> > > fails to handle cases where the sensor data length is too small when reading
> > > the data, resulting in [1] during the read process.
> > 
> > What is "user-forged sensor data"?
> It is the data constructed within the reproducer.

What "reproducer"?

> > > Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> > > Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> > > Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > ---
> > 
> > Was the Assisted-by: tag forgotten?
> No one has assisted me so far; also, I haven't used this type of tag before.

No LLM was used?

> > > +/* aqc_raw_data_valid()
> > > + * Does not support special-case sensor readings data size check
> > 
> > Why not?
> It would be more appropriate for the maintainers of these sensors to add
> the relevant checks.

Why?  Shouldn't that be covered here?

> > > + */
> > > +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> > > +{
> > > +	int off, fan_off, i;
> > > +	char *msg;
> > > +
> > > +	if (!priv)
> > > +		return false;
> > > +
> > > +	/* +1 for get_unaligned_be16(), it reads 2 bytes */
> > > +	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
> > > +	if (off >= size) {
> > > +		msg = "serial number start offset";
> > 
> > That's a lot of debugging code being added, why?  Who is going to use
> > that?
> I am not certain that these debug messages are definitely useful;
> I simply included them because I felt they might be helpful.

If you didn't use them when debugging this code, why would it be needed
by anyone else?

thanks,

greg k-h

Re: [PATCH v4] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Edward Adam Davis]

On Sat, 22 Aug 2026 14:45:27 +0200, Greg KH wrote:
> On Sat, Aug 22, 2026 at 08:23:35PM +0800, Edward Adam Davis wrote:
> > On Sat, 22 Aug 2026 13:55:35 +0200, Greg KH wrote:
> > > On Sat, Aug 22, 2026 at 07:34:35PM +0800, Edward Adam Davis wrote:
> > > > The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> > > > fails to handle cases where the sensor data length is too small when reading
> > > > the data, resulting in [1] during the read process.
> > >
> > > What is "user-forged sensor data"?
> > It is the data constructed within the reproducer.
> 
> What "reproducer"?
The complete reproducer:
https://syzkaller.appspot.com/x/repro.c?x=15a22549580000

Code for constructing the data:
   memcpy((void*)0x200000000500, 
           "\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
           "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
           "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
           "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
           65);
    syz_usb_ep_write(/*fd=*/r[0], /*ep=*/0x81, /*len=*/0x41,
                     /*data=*/0x200000000500);
> 
> > > > Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> > > > Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > > > Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> > > > Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> > > > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > > > ---
> > >
> > > Was the Assisted-by: tag forgotten?
> > No one has assisted me so far; also, I haven't used this type of tag before.
> 
> No LLM was used?
No.
> 
> > > > +/* aqc_raw_data_valid()
> > > > + * Does not support special-case sensor readings data size check
> > >
> > > Why not?
> > It would be more appropriate for the maintainers of these sensors to add
> > the relevant checks.
> 
> Why?  Shouldn't that be covered here?
Perhaps I didn't express myself clearly enough; it should be included here,
but it would be best if someone familiar with Special-case sensors followed
up to add the details.
> 
> > > > + */
> > > > +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> > > > +{
> > > > +	int off, fan_off, i;
> > > > +	char *msg;
> > > > +
> > > > +	if (!priv)
> > > > +		return false;
> > > > +
> > > > +	/* +1 for get_unaligned_be16(), it reads 2 bytes */
> > > > +	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
> > > > +	if (off >= size) {
> > > > +		msg = "serial number start offset";
> > >
> > > That's a lot of debugging code being added, why?  Who is going to use
> > > that?
> > I am not certain that these debug messages are definitely useful;
> > I simply included them because I felt they might be helpful.
> 
> If you didn't use them when debugging this code, why would it be needed
> by anyone else?
That makes perfect sense; I will remove them.

BR,
Edward

[PATCH v5] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Edward Adam Davis]

The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
fails to handle cases where the sensor data length is too small when reading
the data, resulting in [1] during the read process.

Add a data size check, if the size is less than that required for the
specific data item(includes: Physical/Virtual temperature sensor, Flow
sensor, Fan speed and related, etc.) to be read, abort the sensor data
read operation.

[1]
BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
Read of size 2 at addr ffff888108aba257 by task swapper/1/0
Call Trace:
 get_unaligned_be16 include/linux/unaligned.h:48 [inline]
 aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
 aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
 __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
 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

Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: change to check the data item and update comments
v2 -> v3: check all sub items and update subject
v3 -> v4: add speed and flow check
v4 -> v5: remove dbg msg and update comments

 drivers/hwmon/aquacomputer_d5next.c | 81 +++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
index 1ca70e726298..352b227c3015 100644
--- a/drivers/hwmon/aquacomputer_d5next.c
+++ b/drivers/hwmon/aquacomputer_d5next.c
@@ -1324,6 +1324,84 @@ static const struct hwmon_chip_info aqc_chip_info = {
 	.info = aqc_info,
 };
 
+/* aqc_raw_data_valid()
+ * Does not support special-case sensor readings data size check
+ */
+static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
+{
+	int off, fan_off, i;
+
+	if (!priv)
+		return false;
+
+	/* +1 for get_unaligned_be16(), it reads 2 bytes */
+	off = priv->serial_number_start_offset + SERIAL_PART_OFFSET + 1;
+	if (off >= size)
+		goto invalid;
+
+	off = priv->firmware_version_offset + 1;
+	if (off >= size)
+		goto invalid;
+
+	/* Physical temperature sensor */
+	for (i = 0; i < priv->num_temp_sensors; i++) {
+		off = priv->temp_sensor_start_offset + i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size)
+			goto invalid;
+	}
+
+	/* Virtual temperature sensor */
+	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
+		off = priv->virtual_temp_sensor_start_offset +
+		      i * AQC_SENSOR_SIZE + 1;
+
+		if (off >= size)
+			goto invalid;
+	}
+
+	/* Fan speed and related */
+	if (!priv->fan_structure)
+		goto flow;
+
+	for (i = 0; i < priv->num_fans; i++) {
+		fan_off = priv->fan_sensor_offsets[i] + 1;
+		off = fan_off + priv->fan_structure->speed;
+		if (off >= size)
+			goto invalid;
+
+		off = fan_off + priv->fan_structure->power;
+		if (off >= size)
+			goto invalid;
+
+		off = fan_off + priv->fan_structure->voltage;
+		if (off >= size)
+			goto invalid;
+
+		off = fan_off + priv->fan_structure->curr;
+		if (off >= size)
+			goto invalid;
+	}
+
+flow:
+	/* Flow sensor */
+	for (i = 0; i < priv->num_flow_sensors; i++) {
+		off = priv->flow_sensors_start_offset + i * AQC_SENSOR_SIZE + 1;
+		if (off >= size)
+			goto invalid;
+	}
+
+	if (priv->power_cycle_count_offset != 0) {
+		off = priv->power_cycle_count_offset + 3;
+		if (off >= size)
+			goto invalid;
+	}
+
+	return true;
+invalid:
+	return false;
+}
+
 static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8 *data, int size)
 {
 	int i, j, sensor_value;
@@ -1334,6 +1412,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
 
 	priv = hid_get_drvdata(hdev);
 
+	if (!aqc_raw_data_valid(priv, size))
+		return 0;
+
 	/* Info provided with every report */
 	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
 	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +
-- 
2.43.0

Re: [PATCH v5] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete bounds check leaves special-case sensor readings vulnerable to out-of-bounds reads.
- [High] Malicious HID report can trigger a NULL pointer dereference for `aquastreamxt` devices.
--

--- Patch [1]: [PATCH v5] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data ---
commit 0485af53a3a623fa52b28d4e153bb06db94d49e4
Author: Edward Adam Davis <eadavis@qq.com>

hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

This commit adds a data size check for sensor readings in the
aquacomputer_d5next driver to prevent out-of-bounds memory accesses when
processing truncated HID reports.

Link: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37

> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e7262988..352b227c30159 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
> @@ -1324,6 +1324,84 @@ static const struct hwmon_chip_info aqc_chip_info = {
>  	.info = aqc_info,
>  };
>  
> +/* aqc_raw_data_valid()
> + * Does not support special-case sensor readings data size check
> + */

[Severity: High]
This is a pre-existing issue, but since this patch aims to fix out-of-bounds
reads during report processing, is it safe to leave special-case sensor
readings unvalidated?

If a malicious USB device presenting as leakshield, highflownext, or
aquastreamult sends a truncated HID report, it could pass this new generic
validation but still be too small for the special-case fields accessed later.

For example, in aqc_raw_event():

drivers/hwmon/aquacomputer_d5next.c:aqc_raw_event() {
    ...
    switch (priv->kind) {
    ...
    case leakshield:
        priv->speed_input[0] =
            ((s16)get_unaligned_be16(data + LEAKSHIELD_PRESSURE_ADJUSTED)) * 100;
    ...
}

Could this lead to another slab-out-of-bounds read if the report is too small
to contain these offsets?

> +static bool aqc_raw_data_valid(struct aqc_data *priv, int size)
> +{
> +	int off, fan_off, i;
> +
> +	if (!priv)
> +		return false;

[ ... ]

> +	/* Virtual temperature sensor */
> +	for (i = 0; i < priv->num_virtual_temp_sensors; i++) {
> +		off = priv->virtual_temp_sensor_start_offset +
> +		      i * AQC_SENSOR_SIZE + 1;
> +
> +		if (off >= size)
> +			goto invalid;
> +	}
> +
> +	/* Fan speed and related */
> +	if (!priv->fan_structure)
> +		goto flow;

[Severity: High]
This is a pre-existing issue, but does skipping this validation when
priv->fan_structure is NULL expose a NULL pointer dereference later in
aqc_raw_event()?

For devices like aquastreamxt, priv->fan_structure is NULL but priv->num_fans
is greater than 0. Later in aqc_raw_event(), the code loops over num_fans and
unconditionally dereferences fan_structure:

drivers/hwmon/aquacomputer_d5next.c:aqc_raw_event() {
    ...
    /* Fan speed and related readings */
    for (i = 0; i < priv->num_fans; i++) {
        priv->speed_input[i] =
            get_unaligned_be16(data + priv->fan_sensor_offsets[i] +
                               priv->fan_structure->speed);
    ...
}

Could this crash the kernel if a malicious USB device sends a status report
for such a device?

> +
> +	for (i = 0; i < priv->num_fans; i++) {
> +		fan_off = priv->fan_sensor_offsets[i] + 1;
> +		off = fan_off + priv->fan_structure->speed;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_5F7DC370E96643AEA458177FB76E86C8F305@qq.com?part=1

Re: [PATCH v5] hwmon: (aquacomputer_d5next) valid the data size before reading the sensor data

[Guenter Roeck]

On 8/22/26 07:05, Edward Adam Davis wrote:
> The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> fails to handle cases where the sensor data length is too small when reading
> the data, resulting in [1] during the read process.
> 
> Add a data size check, if the size is less than that required for the
> specific data item(includes: Physical/Virtual temperature sensor, Flow
> sensor, Fan speed and related, etc.) to be read, abort the sensor data
> read operation.
> 
> [1]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> Call Trace:
>   get_unaligned_be16 include/linux/unaligned.h:48 [inline]
>   aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
>   aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
>   __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
>   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
> 
> Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> v1 -> v2: change to check the data item and update comments
> v2 -> v3: check all sub items and update subject
> v3 -> v4: add speed and flow check
> v4 -> v5: remove dbg msg and update comments
> 

Your code was and remains way too complicated.

Guenter

Re: [PATCH] hwmon: valid the data size before reading the sensor data

[Guenter Roeck]

Subject is supposed to be "hwmon: (driver) Description".

On 8/21/26 22:34, Edward Adam Davis wrote:
> The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> fails to handle cases where the sensor data length is smaller than the buffer
> size when reading the data, resulting in [1] during the read process.
> 

The device simulated by syzbot is D5 next, and its control buffer size is
0x329 or 809. I _asked_ earlier if that is the value to check against,
but did not claim that this is actually the case.

We know that the report must be much longer than 65 bytes. D5NEXT_PUMP_OFFSET
is 0x6c = 108, and the field is two bytes long, meaning the report size
must be at least 110 bytes long. What we do not know is its actual length.

> Add a check for the data size, if it less than the buffer size, the sensor
> data read is aborted.
>

Apparently Sashiko is aware that this is wrong - not only is the report size
smaller than 809 bytes, but apparently buffer_size is not even set for all
supported devices.

Please do not submit a patch to fix this problem if you can not test if
the code actually works.

Thanks,
Guenter

> [1]
> BUG: KASAN: slab-out-of-bounds in aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
> Read of size 2 at addr ffff888108aba257 by task swapper/1/0
> Call Trace:
>   get_unaligned_be16 include/linux/unaligned.h:48 [inline]
>   aqc_raw_event drivers/hwmon/aquacomputer_d5next.c:1345 [inline]
>   aqc_raw_event+0x213e/0x25d0 drivers/hwmon/aquacomputer_d5next.c:1327
>   __hid_input_report.constprop.0+0x319/0x470 drivers/hid/hid-core.c:2168
>   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
> 
> Fixes: 0e35f63f7f4e ("hwmon: add driver for Aquacomputer D5 Next")
> Reported-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9ee5f5dc18673d6b2f37
> Tested-by: syzbot+9ee5f5dc18673d6b2f37@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>   drivers/hwmon/aquacomputer_d5next.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/hwmon/aquacomputer_d5next.c b/drivers/hwmon/aquacomputer_d5next.c
> index 1ca70e726298..1cc6c220ffe9 100644
> --- a/drivers/hwmon/aquacomputer_d5next.c
> +++ b/drivers/hwmon/aquacomputer_d5next.c
> @@ -1334,6 +1334,9 @@ static int aqc_raw_event(struct hid_device *hdev, struct hid_report *report, u8
>   
>   	priv = hid_get_drvdata(hdev);
>   
> +	if (size < priv->buffer_size)
> +		return 0;
> +
>   	/* Info provided with every report */
>   	priv->serial_number[0] = get_unaligned_be16(data + priv->serial_number_start_offset);
>   	priv->serial_number[1] = get_unaligned_be16(data + priv->serial_number_start_offset +

Re: [PATCH] hwmon: valid the data size before reading the sensor data

[Edward Adam Davis]

On Fri, 21 Aug 2026 23:41:26 -0700, Guenter Roeck wrote:
> Subject is supposed to be "hwmon: (driver) Description".
Oh, got it.
> 
> On 8/21/26 22:34, Edward Adam Davis wrote:
> > The user-forged sensor data is only 65 bytes long; however, aqc_raw_event()
> > fails to handle cases where the sensor data length is smaller than the buffer
> > size when reading the data, resulting in [1] during the read process.
> >
> 
> The device simulated by syzbot is D5 next, and its control buffer size is
> 0x329 or 809. I _asked_ earlier if that is the value to check against,
> but did not claim that this is actually the case.
> 
> We know that the report must be much longer than 65 bytes. D5NEXT_PUMP_OFFSET
> is 0x6c = 108, and the field is two bytes long, meaning the report size
> must be at least 110 bytes long. What we do not know is its actual length.
> 
> > Add a check for the data size, if it less than the buffer size, the sensor
> > data read is aborted.
> >
> 
> Apparently Sashiko is aware that this is wrong - not only is the report size
> smaller than 809 bytes, but apparently buffer_size is not even set for all
> supported devices.
Yes, I also realized that relying solely on the buffer size for the check
might be too simplistic or crude, so I adjusted the data length verification
method and submitted a second version of the patch.

BR,
Edward