* [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
@ 2025-07-14 17:10 syzbot
2025-07-14 18:38 ` Alan Stern
0 siblings, 1 reply; 27+ messages in thread
From: syzbot @ 2025-07-14 17:10 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
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=15a830f0580000
kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 4-1: config 0 descriptor??
microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
shift exponent 4294967295 is too large for 32-bit type 'int'
CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:233 [inline]
__ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
hid_output_field drivers/hid/hid-core.c:1841 [inline]
hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
__hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
hid_connect+0x13f3/0x1a60 drivers/hid/hid-core.c:2239
hid_hw_start drivers/hid/hid-core.c:2354 [inline]
hid_hw_start+0xaa/0x140 drivers/hid/hid-core.c:2345
ms_probe+0x195/0x500 drivers/hid/hid-microsoft.c:391
__hid_device_probe drivers/hid/hid-core.c:2724 [inline]
hid_device_probe+0x363/0x720 drivers/hid/hid-core.c:2761
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
hid_add_device+0x373/0xa60 drivers/hid/hid-core.c:2907
usbhid_probe+0xd38/0x13f0 drivers/hid/usbhid/hid-core.c:1435
usb_probe_interface+0x303/0x9c0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
usb_set_configuration+0x1187/0x1e20 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x3e0 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
usb_new_device+0xd07/0x1a20 drivers/usb/core/hub.c:2694
hub_port_connect drivers/usb/core/hub.c:5566 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5706 [inline]
port_event drivers/usb/core/hub.c:5866 [inline]
hub_event+0x2f85/0x5030 drivers/usb/core/hub.c:5948
process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3321 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3402
kthread+0x3c2/0x780 kernel/kthread.c:464
ret_from_fork+0x5b3/0x6c0 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---[ end trace ]---
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-14 17:10 [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) syzbot
@ 2025-07-14 18:38 ` Alan Stern
2025-07-14 18:50 ` syzbot
2025-07-14 19:48 ` Alan Stern
0 siblings, 2 replies; 27+ messages in thread
From: Alan Stern @ 2025-07-14 18:38 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> 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=15a830f0580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
>
> usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 4-1: config 0 descriptor??
> microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> ------------[ cut here ]------------
> UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> shift exponent 4294967295 is too large for 32-bit type 'int'
> CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> ubsan_epilogue lib/ubsan.c:233 [inline]
> __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> hid_output_field drivers/hid/hid-core.c:1841 [inline]
> hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/hid.git c2ca42f190b6
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-14 18:38 ` Alan Stern
@ 2025-07-14 18:50 ` syzbot
2025-07-14 19:48 ` Alan Stern
1 sibling, 0 replies; 27+ messages in thread
From: syzbot @ 2025-07-14 18:50 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
failed to checkout kernel repo https://git.kernel.org/pub/scm/linux/kernel/git/hid.git on commit c2ca42f190b6: failed to run ["git" "fetch" "--force" "--tags" "0d6f9bdf969aa7d8637c9aa20dfc4a9cfc8f96cd"]: exit status 128
fatal: repository 'https://git.kernel.org/pub/scm/linux/kernel/git/hid.git/' not found
Tested on:
commit: [unknown
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid.git c2ca42f190b6
kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler:
Note: no patches were applied.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-14 18:38 ` Alan Stern
2025-07-14 18:50 ` syzbot
@ 2025-07-14 19:48 ` Alan Stern
2025-07-14 20:28 ` syzbot
2025-07-15 19:29 ` Alan Stern
1 sibling, 2 replies; 27+ messages in thread
From: Alan Stern @ 2025-07-14 19:48 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> 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=15a830f0580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
>
> usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 4-1: config 0 descriptor??
> microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> ------------[ cut here ]------------
> UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> shift exponent 4294967295 is too large for 32-bit type 'int'
> CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> ubsan_epilogue lib/ubsan.c:233 [inline]
> __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> hid_output_field drivers/hid/hid-core.c:1841 [inline]
> hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f190b6
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-14 19:48 ` Alan Stern
@ 2025-07-14 20:28 ` syzbot
2025-07-15 19:29 ` Alan Stern
1 sibling, 0 replies; 27+ messages in thread
From: syzbot @ 2025-07-14 20:28 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
UBSAN: shift-out-of-bounds in s32ton
usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 4-1: config 0 descriptor??
microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
shift exponent 4294967295 is too large for 32-bit type 'int'
CPU: 1 UID: 0 PID: 2803 Comm: kworker/1:2 Not tainted 6.15.0-syzkaller-11339-gc2ca42f190b6 #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
ubsan_epilogue lib/ubsan.c:233 [inline]
__ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
hid_output_field drivers/hid/hid-core.c:1841 [inline]
hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
__hid_request+0x2b4/0x3c0 drivers/hid/hid-core.c:1997
hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
hid_connect+0x13f3/0x1a60 drivers/hid/hid-core.c:2248
hid_hw_start drivers/hid/hid-core.c:2363 [inline]
hid_hw_start+0xaa/0x140 drivers/hid/hid-core.c:2354
ms_probe+0x195/0x500 drivers/hid/hid-microsoft.c:391
__hid_device_probe drivers/hid/hid-core.c:2733 [inline]
hid_device_probe+0x363/0x720 drivers/hid/hid-core.c:2770
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
hid_add_device+0x373/0xa60 drivers/hid/hid-core.c:2916
usbhid_probe+0xd38/0x13f0 drivers/hid/usbhid/hid-core.c:1435
usb_probe_interface+0x303/0x9c0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
usb_set_configuration+0x1187/0x1e20 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x3e0 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:579 [inline]
really_probe+0x23e/0xa90 drivers/base/dd.c:657
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:799
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:957
bus_for_each_drv+0x156/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1029
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1a70 drivers/base/core.c:3692
usb_new_device+0xd07/0x1a20 drivers/usb/core/hub.c:2663
hub_port_connect drivers/usb/core/hub.c:5531 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5671 [inline]
port_event drivers/usb/core/hub.c:5831 [inline]
hub_event+0x2f85/0x5030 drivers/usb/core/hub.c:5913
process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3321 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3402
kthread+0x3c5/0x780 kernel/kthread.c:464
ret_from_fork+0x5b6/0x6c0 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---[ end trace ]---
Tested on:
commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16ecc7d4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=255f64b90a60c429
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
Note: no patches were applied.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-14 19:48 ` Alan Stern
2025-07-14 20:28 ` syzbot
@ 2025-07-15 19:29 ` Alan Stern
2025-07-15 19:50 ` syzbot
` (2 more replies)
1 sibling, 3 replies; 27+ messages in thread
From: Alan Stern @ 2025-07-15 19:29 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> 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=15a830f0580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
>
> usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 4-1: config 0 descriptor??
> microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> ------------[ cut here ]------------
> UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> shift exponent 4294967295 is too large for 32-bit type 'int'
> CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> ubsan_epilogue lib/ubsan.c:233 [inline]
> __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> hid_output_field drivers/hid/hid-core.c:1841 [inline]
> hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f190b6
drivers/hid/hid-core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -1838,9 +1838,12 @@ static void hid_output_field(const struc
for (n = 0; n < count; n++) {
if (field->logical_minimum < 0) /* signed values */
+ {
+ pr_info("s32ton: n %u val %d size 0x%x\n",
+ n, field->value[n], size);
implement(hid, data, offset + n * size, size,
s32ton(field->value[n], size));
- else /* unsigned values */
+ } else /* unsigned values */
implement(hid, data, offset + n * size, size,
field->value[n]);
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-15 19:29 ` Alan Stern
@ 2025-07-15 19:50 ` syzbot
2025-07-16 14:29 ` Alan Stern
2025-07-18 16:08 ` (subset) " Benjamin Tissoires
2025-07-25 11:46 ` Benjamin Tissoires
2 siblings, 1 reply; 27+ messages in thread
From: syzbot @ 2025-07-15 19:50 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
UBSAN: shift-out-of-bounds in s32ton
microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
hid: s32ton: n 0 val 0 size 0x0
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
shift exponent 4294967295 is too large for 32-bit type '__s32' (aka 'int')
CPU: 0 UID: 0 PID: 5987 Comm: kworker/0:4 Not tainted 6.15.0-syzkaller-11339-gc2ca42f190b6-dirty #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
ubsan_epilogue+0xa/0x40 lib/ubsan.c:233
__ubsan_handle_shift_out_of_bounds+0x386/0x410 lib/ubsan.c:494
s32ton+0xde/0x140 drivers/hid/hid-core.c:69
hid_output_field drivers/hid/hid-core.c:1845 [inline]
hid_output_report+0x3a2/0x5c0 drivers/hid/hid-core.c:1877
__hid_request+0x14a/0x420 drivers/hid/hid-core.c:2000
hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
hidinput_connect+0x218a/0x3030 drivers/hid/hid-input.c:2327
hid_connect+0x499/0x1980 drivers/hid/hid-core.c:2251
hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2366
ms_probe+0x180/0x430 drivers/hid/hid-microsoft.c:391
__hid_device_probe drivers/hid/hid-core.c:2736 [inline]
hid_device_probe+0x3a0/0x710 drivers/hid/hid-core.c:2773
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
hid_add_device+0x398/0x540 drivers/hid/hid-core.c:2919
usbhid_probe+0xe13/0x12a0 drivers/hid/usbhid/hid-core.c:1435
usb_probe_interface+0x644/0xbc0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
usb_set_configuration+0x1a87/0x20e0 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0x8d/0x150 drivers/usb/core/generic.c:250
usb_probe_device+0x1c4/0x390 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
usb_new_device+0xa39/0x16c0 drivers/usb/core/hub.c:2663
hub_port_connect drivers/usb/core/hub.c:5531 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5671 [inline]
port_event drivers/usb/core/hub.c:5831 [inline]
hub_event+0x2941/0x4a00 drivers/usb/core/hub.c:5913
process_one_work kernel/workqueue.c:3238 [inline]
process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321
worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
kthread+0x70e/0x8a0 kernel/kthread.c:464
ret_from_fork+0x3f9/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---[ end trace ]---
Tested on:
commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
console output: https://syzkaller.appspot.com/x/log.txt?x=152e098c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ec692dfd475747ff
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch: https://syzkaller.appspot.com/x/patch.diff?x=13b6098c580000
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-15 19:50 ` syzbot
@ 2025-07-16 14:29 ` Alan Stern
2025-07-16 14:50 ` syzbot
2025-07-16 15:58 ` Alan Stern
0 siblings, 2 replies; 27+ messages in thread
From: Alan Stern @ 2025-07-16 14:29 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Tue, Jul 15, 2025 at 12:50:04PM -0700, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> UBSAN: shift-out-of-bounds in s32ton
>
> microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> hid: s32ton: n 0 val 0 size 0x0
> ------------[ cut here ]------------
> UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> shift exponent 4294967295 is too large for 32-bit type '__s32' (aka 'int')
Benjamin:
Clearly there's going to be trouble when you try to convert a signed
32-bit value to a 0-bit number!
My impression is that hid_parser_global() should reject Report Size or
Report Count items with a value of 0. Such fields would be meaningless
in any case. The routine checks for values that are too large, but not
for values that are too small.
Does this look like the right approach?
Alan Stern
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f1
drivers/hid/hid-core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -464,7 +464,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
parser->global.report_size = item_udata(item);
- if (parser->global.report_size > 256) {
+ if (parser->global.report_size > 256 ||
+ parser->global.report_size == 0) {
hid_err(parser->device, "invalid report_size %d\n",
parser->global.report_size);
return -1;
@@ -473,7 +474,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
parser->global.report_count = item_udata(item);
- if (parser->global.report_count > HID_MAX_USAGES) {
+ if (parser->global.report_count > HID_MAX_USAGES ||
+ parser->global.report_count == 0) {
hid_err(parser->device, "invalid report_count %d\n",
parser->global.report_count);
return -1;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-16 14:29 ` Alan Stern
@ 2025-07-16 14:50 ` syzbot
2025-07-16 15:58 ` Alan Stern
1 sibling, 0 replies; 27+ messages in thread
From: syzbot @ 2025-07-16 14:50 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
UBSAN: shift-out-of-bounds in s32ton
usb 1-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
usb 1-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
------------[ cut here ]------------
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
shift exponent 4294967295 is too large for 32-bit type '__s32' (aka 'int')
CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-syzkaller-11339-gc2ca42f190b6-dirty #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
ubsan_epilogue+0xa/0x40 lib/ubsan.c:233
__ubsan_handle_shift_out_of_bounds+0x386/0x410 lib/ubsan.c:494
s32ton+0xde/0x140 drivers/hid/hid-core.c:69
hid_output_field drivers/hid/hid-core.c:1844 [inline]
hid_output_report+0x419/0x790 drivers/hid/hid-core.c:1876
__hid_request+0x14a/0x420 drivers/hid/hid-core.c:1999
hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
hidinput_connect+0x218a/0x3030 drivers/hid/hid-input.c:2327
hid_connect+0x499/0x1980 drivers/hid/hid-core.c:2250
hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2365
ms_probe+0x180/0x430 drivers/hid/hid-microsoft.c:391
__hid_device_probe drivers/hid/hid-core.c:2735 [inline]
hid_device_probe+0x3a0/0x710 drivers/hid/hid-core.c:2772
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
hid_add_device+0x398/0x540 drivers/hid/hid-core.c:2918
usbhid_probe+0xe13/0x12a0 drivers/hid/usbhid/hid-core.c:1435
usb_probe_interface+0x644/0xbc0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
usb_set_configuration+0x1a87/0x20e0 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0x8d/0x150 drivers/usb/core/generic.c:250
usb_probe_device+0x1c4/0x390 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x26a/0x9a0 drivers/base/dd.c:657
__driver_probe_device+0x18c/0x2f0 drivers/base/dd.c:799
driver_probe_device+0x4f/0x430 drivers/base/dd.c:829
__device_attach_driver+0x2ce/0x530 drivers/base/dd.c:957
bus_for_each_drv+0x251/0x2e0 drivers/base/bus.c:462
__device_attach+0x2b8/0x400 drivers/base/dd.c:1029
bus_probe_device+0x185/0x260 drivers/base/bus.c:537
device_add+0x7b6/0xb50 drivers/base/core.c:3692
usb_new_device+0xa39/0x16c0 drivers/usb/core/hub.c:2663
hub_port_connect drivers/usb/core/hub.c:5531 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5671 [inline]
port_event drivers/usb/core/hub.c:5831 [inline]
hub_event+0x2941/0x4a00 drivers/usb/core/hub.c:5913
process_one_work kernel/workqueue.c:3238 [inline]
process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321
worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
kthread+0x70e/0x8a0 kernel/kthread.c:464
ret_from_fork+0x3f9/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---[ end trace ]---
Tested on:
commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16e948f0580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ec692dfd475747ff
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch: https://syzkaller.appspot.com/x/patch.diff?x=13f6f58c580000
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-16 14:29 ` Alan Stern
2025-07-16 14:50 ` syzbot
@ 2025-07-16 15:58 ` Alan Stern
2025-07-17 11:48 ` Benjamin Tissoires
1 sibling, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-16 15:58 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Benjamin:
On Wed, Jul 16, 2025 at 10:29:38AM -0400, Alan Stern wrote:
> On Tue, Jul 15, 2025 at 12:50:04PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > UBSAN: shift-out-of-bounds in s32ton
> >
> > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > hid: s32ton: n 0 val 0 size 0x0
> > ------------[ cut here ]------------
> > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > shift exponent 4294967295 is too large for 32-bit type '__s32' (aka 'int')
>
> Benjamin:
>
> Clearly there's going to be trouble when you try to convert a signed
> 32-bit value to a 0-bit number!
>
> My impression is that hid_parser_global() should reject Report Size or
> Report Count items with a value of 0. Such fields would be meaningless
> in any case. The routine checks for values that are too large, but not
> for values that are too small.
>
> Does this look like the right approach?
>
> Alan Stern
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f1
>
> drivers/hid/hid-core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Index: usb-devel/drivers/hid/hid-core.c
> ===================================================================
> --- usb-devel.orig/drivers/hid/hid-core.c
> +++ usb-devel/drivers/hid/hid-core.c
> @@ -464,7 +464,8 @@ static int hid_parser_global(struct hid_
>
> case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
> parser->global.report_size = item_udata(item);
> - if (parser->global.report_size > 256) {
> + if (parser->global.report_size > 256 ||
> + parser->global.report_size == 0) {
> hid_err(parser->device, "invalid report_size %d\n",
> parser->global.report_size);
> return -1;
> @@ -473,7 +474,8 @@ static int hid_parser_global(struct hid_
>
> case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
> parser->global.report_count = item_udata(item);
> - if (parser->global.report_count > HID_MAX_USAGES) {
> + if (parser->global.report_count > HID_MAX_USAGES ||
> + parser->global.report_count == 0) {
> hid_err(parser->device, "invalid report_count %d\n",
> parser->global.report_count);
> return -1;
This patch didn't work; the error message never showed up in the kernel
log. Nevertheless, hidinput_change_resolution_multipliers() tried to
create an output report with a field having size 0.
How can this to happen without hid_scan_report() or hid_open_report()
running? It shouldn't be possible to use a report before it has been
checked for validity.
Alan Stern
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-16 15:58 ` Alan Stern
@ 2025-07-17 11:48 ` Benjamin Tissoires
2025-07-17 15:10 ` Alan Stern
0 siblings, 1 reply; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-17 11:48 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Hi Alan,
On Jul 16 2025, Alan Stern wrote:
> Benjamin:
>
> On Wed, Jul 16, 2025 at 10:29:38AM -0400, Alan Stern wrote:
> > On Tue, Jul 15, 2025 at 12:50:04PM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > UBSAN: shift-out-of-bounds in s32ton
> > >
> > > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > > hid: s32ton: n 0 val 0 size 0x0
> > > ------------[ cut here ]------------
> > > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > > shift exponent 4294967295 is too large for 32-bit type '__s32' (aka 'int')
> >
> > Benjamin:
> >
> > Clearly there's going to be trouble when you try to convert a signed
> > 32-bit value to a 0-bit number!
> >
> > My impression is that hid_parser_global() should reject Report Size or
> > Report Count items with a value of 0. Such fields would be meaningless
> > in any case. The routine checks for values that are too large, but not
> > for values that are too small.
> >
> > Does this look like the right approach?
> >
> > Alan Stern
> >
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f1
> >
> > drivers/hid/hid-core.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > Index: usb-devel/drivers/hid/hid-core.c
> > ===================================================================
> > --- usb-devel.orig/drivers/hid/hid-core.c
> > +++ usb-devel/drivers/hid/hid-core.c
> > @@ -464,7 +464,8 @@ static int hid_parser_global(struct hid_
> >
> > case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
> > parser->global.report_size = item_udata(item);
> > - if (parser->global.report_size > 256) {
> > + if (parser->global.report_size > 256 ||
> > + parser->global.report_size == 0) {
> > hid_err(parser->device, "invalid report_size %d\n",
> > parser->global.report_size);
> > return -1;
> > @@ -473,7 +474,8 @@ static int hid_parser_global(struct hid_
> >
> > case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
> > parser->global.report_count = item_udata(item);
> > - if (parser->global.report_count > HID_MAX_USAGES) {
> > + if (parser->global.report_count > HID_MAX_USAGES ||
> > + parser->global.report_count == 0) {
> > hid_err(parser->device, "invalid report_count %d\n",
> > parser->global.report_count);
> > return -1;
>
> This patch didn't work; the error message never showed up in the kernel
> log. Nevertheless, hidinput_change_resolution_multipliers() tried to
> create an output report with a field having size 0.
>
> How can this to happen without hid_scan_report() or hid_open_report()
> running? It shouldn't be possible to use a report before it has been
> checked for validity.
It's just that the provided report descriptor was never setting a report
size or a report count. This way, we are stuck with the default value
from kzalloc: 0.
Basically, if your report descriptor is as simple as:
Usage Page (Generic Desktop)
Usage (X)
Usage (Y)
Report Count (2)
Input (Data,Var,Rel)
Then we would trigger this bug: "report Size" is never set and is thus 0.
Your patch is good though, as it is probably a good thing to prevent a
report size/count to be 0. But it's not addressing the issue here
because the only time we can check for those values is when we receive
an Input/Feature/Output value (or ranges), so in hid_add_field().
Cheers,
Benjamin
>
> Alan Stern
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-17 11:48 ` Benjamin Tissoires
@ 2025-07-17 15:10 ` Alan Stern
2025-07-17 15:49 ` syzbot
0 siblings, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-17 15:10 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Thu, Jul 17, 2025 at 01:48:41PM +0200, Benjamin Tissoires wrote:
> Hi Alan,
>
> On Jul 16 2025, Alan Stern wrote:
> > > Benjamin:
> > >
> > > Clearly there's going to be trouble when you try to convert a signed
> > > 32-bit value to a 0-bit number!
> > >
> > > My impression is that hid_parser_global() should reject Report Size or
> > > Report Count items with a value of 0. Such fields would be meaningless
> > > in any case. The routine checks for values that are too large, but not
> > > for values that are too small.
> > >
> > > Does this look like the right approach?
...
> > This patch didn't work; the error message never showed up in the kernel
> > log. Nevertheless, hidinput_change_resolution_multipliers() tried to
> > create an output report with a field having size 0.
> >
> > How can this to happen without hid_scan_report() or hid_open_report()
> > running? It shouldn't be possible to use a report before it has been
> > checked for validity.
>
> It's just that the provided report descriptor was never setting a report
> size or a report count. This way, we are stuck with the default value
> from kzalloc: 0.
>
> Basically, if your report descriptor is as simple as:
> Usage Page (Generic Desktop)
> Usage (X)
> Usage (Y)
> Report Count (2)
> Input (Data,Var,Rel)
>
> Then we would trigger this bug: "report Size" is never set and is thus 0.
>
> Your patch is good though, as it is probably a good thing to prevent a
> report size/count to be 0. But it's not addressing the issue here
> because the only time we can check for those values is when we receive
> an Input/Feature/Output value (or ranges), so in hid_add_field().
Of course! Thanks for the pointer. Let's try it out.
Alan Stern
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f190b6
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -313,7 +313,14 @@ static int hid_add_field(struct hid_pars
}
offset = report->size;
- report->size += parser->global.report_size * parser->global.report_count;
+ i = parser->global.report_size * parser->global.report_count;
+ if (i == 0) {
+ dbg_hid("invalid field size/count 0x%x 0x%x\n",
+ parser->global.report_size,
+ parser->global.report_count);
+ return -1;
+ }
+ report->size += i;
if (parser->device->ll_driver->max_buffer_size)
max_buffer_size = parser->device->ll_driver->max_buffer_size;
@@ -464,7 +471,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
parser->global.report_size = item_udata(item);
- if (parser->global.report_size > 256) {
+ if (parser->global.report_size > 256 ||
+ parser->global.report_size == 0) {
hid_err(parser->device, "invalid report_size %d\n",
parser->global.report_size);
return -1;
@@ -473,7 +481,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
parser->global.report_count = item_udata(item);
- if (parser->global.report_count > HID_MAX_USAGES) {
+ if (parser->global.report_count > HID_MAX_USAGES ||
+ parser->global.report_count == 0) {
hid_err(parser->device, "invalid report_count %d\n",
parser->global.report_count);
return -1;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-17 15:10 ` Alan Stern
@ 2025-07-17 15:49 ` syzbot
2025-07-18 2:33 ` [PATCH] HID: core: Reject report fields with a size or count of 0 Alan Stern
2025-07-21 14:37 ` [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) Alan Stern
0 siblings, 2 replies; 27+ messages in thread
From: syzbot @ 2025-07-17 15:49 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Tested on:
commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
console output: https://syzkaller.appspot.com/x/log.txt?x=148b258c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ec692dfd475747ff
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch: https://syzkaller.appspot.com/x/patch.diff?x=14dd1382580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-17 15:49 ` syzbot
@ 2025-07-18 2:33 ` Alan Stern
2025-07-19 8:36 ` Benjamin Tissoires
2025-07-21 14:37 ` [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) Alan Stern
1 sibling, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-18 2:33 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity. This is hardly an unexpected result,
but it means that we should not accept report fields that have a size
of zero bits. Similarly, there's no reason to accept report fields
with a count of zero; either type of item is completely meaningless
since no information can be conveyed in zero bits.
Reject fields with a size or count of zero, and reject reports
containing such fields.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Cc: stable@vger.kernel.org
---
The commit listed in the Fixes tag is not really the right one. But
code motion made tracking it back any further more difficult than I
wanted to deal with, so I stopped there. That commit is from 2006,
which is already far enough in the past.
drivers/hid/hid-core.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -313,7 +313,14 @@ static int hid_add_field(struct hid_pars
}
offset = report->size;
- report->size += parser->global.report_size * parser->global.report_count;
+ i = parser->global.report_size * parser->global.report_count;
+ if (i == 0) {
+ dbg_hid("invalid field size/count 0x%x 0x%x\n",
+ parser->global.report_size,
+ parser->global.report_count);
+ return -1;
+ }
+ report->size += i;
if (parser->device->ll_driver->max_buffer_size)
max_buffer_size = parser->device->ll_driver->max_buffer_size;
@@ -464,7 +471,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
parser->global.report_size = item_udata(item);
- if (parser->global.report_size > 256) {
+ if (parser->global.report_size > 256 ||
+ parser->global.report_size == 0) {
hid_err(parser->device, "invalid report_size %d\n",
parser->global.report_size);
return -1;
@@ -473,7 +481,8 @@ static int hid_parser_global(struct hid_
case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
parser->global.report_count = item_udata(item);
- if (parser->global.report_count > HID_MAX_USAGES) {
+ if (parser->global.report_count > HID_MAX_USAGES ||
+ parser->global.report_count == 0) {
hid_err(parser->device, "invalid report_count %d\n",
parser->global.report_count);
return -1;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: (subset) [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-15 19:29 ` Alan Stern
2025-07-15 19:50 ` syzbot
@ 2025-07-18 16:08 ` Benjamin Tissoires
2025-07-23 9:36 ` Benjamin Tissoires
2025-07-25 11:46 ` Benjamin Tissoires
2 siblings, 1 reply; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-18 16:08 UTC (permalink / raw)
To: syzbot, Alan Stern
Cc: jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs
On Tue, 15 Jul 2025 15:29:25 -0400, Alan Stern wrote:
> On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> > 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=15a830f0580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> > compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> >
> > usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> > usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> > usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > usb 4-1: config 0 descriptor??
> > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > ------------[ cut here ]------------
> > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > shift exponent 4294967295 is too large for 32-bit type 'int'
> > CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > <TASK>
> > __dump_stack lib/dump_stack.c:94 [inline]
> > dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> > ubsan_epilogue lib/ubsan.c:233 [inline]
> > __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> > s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> > hid_output_field drivers/hid/hid-core.c:1841 [inline]
> > hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> > __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> > hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> > hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
>
> [...]
Applied to hid/hid.git (for-6.17/core), thanks!
[1/1] HID: core: Reject report fields with a size or count of 0
https://git.kernel.org/hid/hid/c/bcf266ca2779
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-18 2:33 ` [PATCH] HID: core: Reject report fields with a size or count of 0 Alan Stern
@ 2025-07-19 8:36 ` Benjamin Tissoires
2025-07-19 8:40 ` Benjamin Tissoires
2025-07-19 14:48 ` Alan Stern
0 siblings, 2 replies; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-19 8:36 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Jul 17 2025, Alan Stern wrote:
> Testing by the syzbot fuzzer showed that the HID core gets a
> shift-out-of-bounds exception when it tries to convert a 32-bit
> quantity to a 0-bit quantity. This is hardly an unexpected result,
> but it means that we should not accept report fields that have a size
> of zero bits. Similarly, there's no reason to accept report fields
> with a count of zero; either type of item is completely meaningless
> since no information can be conveyed in zero bits.
>
> Reject fields with a size or count of zero, and reject reports
> containing such fields.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
> Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> Cc: stable@vger.kernel.org
>
> ---
>
> The commit listed in the Fixes tag is not really the right one. But
> code motion made tracking it back any further more difficult than I
> wanted to deal with, so I stopped there. That commit is from 2006,
> which is already far enough in the past.
>
> drivers/hid/hid-core.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> Index: usb-devel/drivers/hid/hid-core.c
> ===================================================================
> --- usb-devel.orig/drivers/hid/hid-core.c
> +++ usb-devel/drivers/hid/hid-core.c
> @@ -313,7 +313,14 @@ static int hid_add_field(struct hid_pars
> }
>
> offset = report->size;
> - report->size += parser->global.report_size * parser->global.report_count;
> + i = parser->global.report_size * parser->global.report_count;
> + if (i == 0) {
> + dbg_hid("invalid field size/count 0x%x 0x%x\n",
> + parser->global.report_size,
> + parser->global.report_count);
> + return -1;
> + }
> + report->size += i;
>
> if (parser->device->ll_driver->max_buffer_size)
> max_buffer_size = parser->device->ll_driver->max_buffer_size;
> @@ -464,7 +471,8 @@ static int hid_parser_global(struct hid_
>
> case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
> parser->global.report_size = item_udata(item);
> - if (parser->global.report_size > 256) {
> + if (parser->global.report_size > 256 ||
> + parser->global.report_size == 0) {
> hid_err(parser->device, "invalid report_size %d\n",
> parser->global.report_size);
> return -1;
Sigh... I applied this one too quickly before going on holidays.
This breaks the hid testsuite:
https://gitlab.freedesktop.org/bentiss/hid/-/jobs/80805946
(yes, I should have run it before applying).
So basically, there are devices out there with a "broken" report size of
0, and this patch now entirely disables them.
That Saitek gamepad has the following (see tools/testing/selftests/hid/tests/test_gamepad.py):
0x95, 0x01, # ..Report Count (1) 60
0x75, 0x00, # ..Report Size (0) 62
0x81, 0x03, # ..Input (Cnst,Var,Abs) 64
So we'd need to disable the field, but not invalidate the entire report.
I'm glad I scheduled this one for the next cycle.
I'll try to get something next week.
Cheers,
Benjamin
> @@ -473,7 +481,8 @@ static int hid_parser_global(struct hid_
>
> case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
> parser->global.report_count = item_udata(item);
> - if (parser->global.report_count > HID_MAX_USAGES) {
> + if (parser->global.report_count > HID_MAX_USAGES ||
> + parser->global.report_count == 0) {
> hid_err(parser->device, "invalid report_count %d\n",
> parser->global.report_count);
> return -1;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-19 8:36 ` Benjamin Tissoires
@ 2025-07-19 8:40 ` Benjamin Tissoires
2025-07-19 14:48 ` Alan Stern
1 sibling, 0 replies; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-19 8:40 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Jul 19 2025, Benjamin Tissoires wrote:
> On Jul 17 2025, Alan Stern wrote:
> > Testing by the syzbot fuzzer showed that the HID core gets a
> > shift-out-of-bounds exception when it tries to convert a 32-bit
> > quantity to a 0-bit quantity. This is hardly an unexpected result,
> > but it means that we should not accept report fields that have a size
> > of zero bits. Similarly, there's no reason to accept report fields
> > with a count of zero; either type of item is completely meaningless
> > since no information can be conveyed in zero bits.
> >
> > Reject fields with a size or count of zero, and reject reports
> > containing such fields.
> >
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
> > Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> > Cc: stable@vger.kernel.org
> >
> > ---
> >
> > The commit listed in the Fixes tag is not really the right one. But
> > code motion made tracking it back any further more difficult than I
> > wanted to deal with, so I stopped there. That commit is from 2006,
> > which is already far enough in the past.
> >
> > drivers/hid/hid-core.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > Index: usb-devel/drivers/hid/hid-core.c
> > ===================================================================
> > --- usb-devel.orig/drivers/hid/hid-core.c
> > +++ usb-devel/drivers/hid/hid-core.c
> > @@ -313,7 +313,14 @@ static int hid_add_field(struct hid_pars
> > }
> >
> > offset = report->size;
> > - report->size += parser->global.report_size * parser->global.report_count;
> > + i = parser->global.report_size * parser->global.report_count;
> > + if (i == 0) {
> > + dbg_hid("invalid field size/count 0x%x 0x%x\n",
> > + parser->global.report_size,
> > + parser->global.report_count);
> > + return -1;
> > + }
> > + report->size += i;
> >
> > if (parser->device->ll_driver->max_buffer_size)
> > max_buffer_size = parser->device->ll_driver->max_buffer_size;
> > @@ -464,7 +471,8 @@ static int hid_parser_global(struct hid_
> >
> > case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
> > parser->global.report_size = item_udata(item);
> > - if (parser->global.report_size > 256) {
> > + if (parser->global.report_size > 256 ||
> > + parser->global.report_size == 0) {
> > hid_err(parser->device, "invalid report_size %d\n",
> > parser->global.report_size);
> > return -1;
>
> Sigh... I applied this one too quickly before going on holidays.
>
> This breaks the hid testsuite:
> https://gitlab.freedesktop.org/bentiss/hid/-/jobs/80805946
>
> (yes, I should have run it before applying).
>
> So basically, there are devices out there with a "broken" report size of
> 0, and this patch now entirely disables them.
>
> That Saitek gamepad has the following (see tools/testing/selftests/hid/tests/test_gamepad.py):
> 0x95, 0x01, # ..Report Count (1) 60
> 0x75, 0x00, # ..Report Size (0) 62
> 0x81, 0x03, # ..Input (Cnst,Var,Abs) 64
>
> So we'd need to disable the field, but not invalidate the entire report.
>
> I'm glad I scheduled this one for the next cycle.
>
> I'll try to get something next week.
>
In case you are interested in fixing this, a quick reproducer can be
done through virtme-ng:
$> vng --verbose --kconfig --skip-module --config tools/testing/selftests/hid/config
$> make -j8
$> vng -v --user root --exec "mount bpffs -t bpf /sys/fs/bpf ; pytest ./tools/testing/selftests/hid/tests/test_gamepad.py -v -x --color=yes -k Saitek"
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-19 8:36 ` Benjamin Tissoires
2025-07-19 8:40 ` Benjamin Tissoires
@ 2025-07-19 14:48 ` Alan Stern
2025-07-21 13:05 ` Benjamin Tissoires
1 sibling, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-19 14:48 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Sat, Jul 19, 2025 at 10:36:01AM +0200, Benjamin Tissoires wrote:
> On Jul 17 2025, Alan Stern wrote:
> > Testing by the syzbot fuzzer showed that the HID core gets a
> > shift-out-of-bounds exception when it tries to convert a 32-bit
> > quantity to a 0-bit quantity. This is hardly an unexpected result,
> > but it means that we should not accept report fields that have a size
> > of zero bits. Similarly, there's no reason to accept report fields
> > with a count of zero; either type of item is completely meaningless
> > since no information can be conveyed in zero bits.
> >
> > Reject fields with a size or count of zero, and reject reports
> > containing such fields.
> >
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
> > Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> > Cc: stable@vger.kernel.org
> Sigh... I applied this one too quickly before going on holidays.
>
> This breaks the hid testsuite:
> https://gitlab.freedesktop.org/bentiss/hid/-/jobs/80805946
>
> (yes, I should have run it before applying).
>
> So basically, there are devices out there with a "broken" report size of
> 0, and this patch now entirely disables them.
>
> That Saitek gamepad has the following (see tools/testing/selftests/hid/tests/test_gamepad.py):
> 0x95, 0x01, # ..Report Count (1) 60
> 0x75, 0x00, # ..Report Size (0) 62
> 0x81, 0x03, # ..Input (Cnst,Var,Abs) 64
>
> So we'd need to disable the field, but not invalidate the entire report.
>
> I'm glad I scheduled this one for the next cycle.
>
> I'll try to get something next week.
So then would it be better to accept these report fields (perhaps with a
warning) and instead, harden the core HID code so that it doesn't choke
when it runs across one of them?
Alan Stern
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-19 14:48 ` Alan Stern
@ 2025-07-21 13:05 ` Benjamin Tissoires
2025-07-21 13:56 ` Alan Stern
0 siblings, 1 reply; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-21 13:05 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Jul 19 2025, Alan Stern wrote:
> On Sat, Jul 19, 2025 at 10:36:01AM +0200, Benjamin Tissoires wrote:
> > On Jul 17 2025, Alan Stern wrote:
> > > Testing by the syzbot fuzzer showed that the HID core gets a
> > > shift-out-of-bounds exception when it tries to convert a 32-bit
> > > quantity to a 0-bit quantity. This is hardly an unexpected result,
> > > but it means that we should not accept report fields that have a size
> > > of zero bits. Similarly, there's no reason to accept report fields
> > > with a count of zero; either type of item is completely meaningless
> > > since no information can be conveyed in zero bits.
> > >
> > > Reject fields with a size or count of zero, and reject reports
> > > containing such fields.
> > >
> > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > > Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
> > > Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> > > Cc: stable@vger.kernel.org
>
> > Sigh... I applied this one too quickly before going on holidays.
> >
> > This breaks the hid testsuite:
> > https://gitlab.freedesktop.org/bentiss/hid/-/jobs/80805946
> >
> > (yes, I should have run it before applying).
> >
> > So basically, there are devices out there with a "broken" report size of
> > 0, and this patch now entirely disables them.
> >
> > That Saitek gamepad has the following (see tools/testing/selftests/hid/tests/test_gamepad.py):
> > 0x95, 0x01, # ..Report Count (1) 60
> > 0x75, 0x00, # ..Report Size (0) 62
> > 0x81, 0x03, # ..Input (Cnst,Var,Abs) 64
> >
> > So we'd need to disable the field, but not invalidate the entire report.
> >
> > I'm glad I scheduled this one for the next cycle.
> >
> > I'll try to get something next week.
>
> So then would it be better to accept these report fields (perhaps with a
> warning) and instead, harden the core HID code so that it doesn't choke
> when it runs across one of them?
>
Yeah, that seems like the best plan forward.
[sorry on reduced setup for the next 3 weeks, so I can't really debug
the entire thing now.]
Though, we should probably not annoy users unless we are trying to do
something that won't be needed. I doubt that Saitek gamepad will ever
call the faulty functions, so why putting an error in the logs when it's
working fine?
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-21 13:05 ` Benjamin Tissoires
@ 2025-07-21 13:56 ` Alan Stern
2025-07-23 9:32 ` Benjamin Tissoires
0 siblings, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-21 13:56 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Mon, Jul 21, 2025 at 03:05:58PM +0200, Benjamin Tissoires wrote:
> > So then would it be better to accept these report fields (perhaps with a
> > warning) and instead, harden the core HID code so that it doesn't choke
> > when it runs across one of them?
> >
>
> Yeah, that seems like the best plan forward.
>
> [sorry on reduced setup for the next 3 weeks, so I can't really debug
> the entire thing now.]
>
> Though, we should probably not annoy users unless we are trying to do
> something that won't be needed. I doubt that Saitek gamepad will ever
> call the faulty functions, so why putting an error in the logs when it's
> working fine?
All right.
Probably the best way to do this is simply to revert the commit that's
already applied and then merge a new patch to harden the core. Would
you like me to post the reversion patch or do you prefer to do it
yourself?
Alan Stern
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-17 15:49 ` syzbot
2025-07-18 2:33 ` [PATCH] HID: core: Reject report fields with a size or count of 0 Alan Stern
@ 2025-07-21 14:37 ` Alan Stern
2025-07-21 15:23 ` syzbot
1 sibling, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-21 14:37 UTC (permalink / raw)
To: syzbot; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Thu, Jul 17, 2025 at 08:49:03AM -0700, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch and the reproducer did not trigger any issue:
>
> Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
>
> Tested on:
>
> commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=148b258c580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ec692dfd475747ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> patch: https://syzkaller.appspot.com/x/patch.diff?x=14dd1382580000
>
> Note: testing is done by a robot and is best-effort only.
Let's try a different approach: hardening against invalid field
attributes. As far as I can tell on a quick scan through the code, only
one change is needed.
Alan Stern
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f190b6
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -66,8 +66,12 @@ static s32 snto32(__u32 value, unsigned
static u32 s32ton(__s32 value, unsigned int n)
{
- s32 a = value >> (n - 1);
+ s32 a;
+ if (!value || !n)
+ return 0;
+
+ a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
return value & ((1 << n) - 1);
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-21 14:37 ` [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) Alan Stern
@ 2025-07-21 15:23 ` syzbot
0 siblings, 0 replies; 27+ messages in thread
From: syzbot @ 2025-07-21 15:23 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb, stern,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Tested on:
commit: c2ca42f1 HID: core: do not bypass hid_hw_raw_request
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16f4cf22580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ec692dfd475747ff
dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch: https://syzkaller.appspot.com/x/patch.diff?x=142bef22580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-21 13:56 ` Alan Stern
@ 2025-07-23 9:32 ` Benjamin Tissoires
2025-07-23 14:34 ` Alan Stern
0 siblings, 1 reply; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-23 9:32 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Jul 21 2025, Alan Stern wrote:
> On Mon, Jul 21, 2025 at 03:05:58PM +0200, Benjamin Tissoires wrote:
> > > So then would it be better to accept these report fields (perhaps with a
> > > warning) and instead, harden the core HID code so that it doesn't choke
> > > when it runs across one of them?
> > >
> >
> > Yeah, that seems like the best plan forward.
> >
> > [sorry on reduced setup for the next 3 weeks, so I can't really debug
> > the entire thing now.]
> >
> > Though, we should probably not annoy users unless we are trying to do
> > something that won't be needed. I doubt that Saitek gamepad will ever
> > call the faulty functions, so why putting an error in the logs when it's
> > working fine?
>
> All right.
>
> Probably the best way to do this is simply to revert the commit that's
> already applied and then merge a new patch to harden the core. Would
> you like me to post the reversion patch or do you prefer to do it
> yourself?
Given that the faulty commit is on top of for-6.17/core, I can simply
force push to the parent, and also force push the for-next branch. That
should do the trick.
Can you post your s32ton fix on top of that then?
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: (subset) [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-18 16:08 ` (subset) " Benjamin Tissoires
@ 2025-07-23 9:36 ` Benjamin Tissoires
0 siblings, 0 replies; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-23 9:36 UTC (permalink / raw)
To: syzbot, Alan Stern
Cc: jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs
On Jul 18 2025, Benjamin Tissoires wrote:
> On Tue, 15 Jul 2025 15:29:25 -0400, Alan Stern wrote:
> > On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> > > 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=15a830f0580000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> > > compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> > >
> > > usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> > > usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> > > usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > > usb 4-1: config 0 descriptor??
> > > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > > ------------[ cut here ]------------
> > > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > > shift exponent 4294967295 is too large for 32-bit type 'int'
> > > CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> > > Workqueue: usb_hub_wq hub_event
> > > Call Trace:
> > > <TASK>
> > > __dump_stack lib/dump_stack.c:94 [inline]
> > > dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> > > ubsan_epilogue lib/ubsan.c:233 [inline]
> > > __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> > > s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> > > hid_output_field drivers/hid/hid-core.c:1841 [inline]
> > > hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> > > __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> > > hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> > > hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
> >
> > [...]
>
> Applied to hid/hid.git (for-6.17/core), thanks!
>
> [1/1] HID: core: Reject report fields with a size or count of 0
> https://git.kernel.org/hid/hid/c/bcf266ca2779
FTR, the patch has been dropped from for-next, it broke existing
devices. A better patch is being worked on.
Cheers,
Benjamin
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] HID: core: Reject report fields with a size or count of 0
2025-07-23 9:32 ` Benjamin Tissoires
@ 2025-07-23 14:34 ` Alan Stern
2025-07-23 14:37 ` [PATCH] HID: core: Harden s32ton() against conversion to 0 bits Alan Stern
0 siblings, 1 reply; 27+ messages in thread
From: Alan Stern @ 2025-07-23 14:34 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
On Wed, Jul 23, 2025 at 11:32:14AM +0200, Benjamin Tissoires wrote:
> On Jul 21 2025, Alan Stern wrote:
> > On Mon, Jul 21, 2025 at 03:05:58PM +0200, Benjamin Tissoires wrote:
> > > > So then would it be better to accept these report fields (perhaps with a
> > > > warning) and instead, harden the core HID code so that it doesn't choke
> > > > when it runs across one of them?
> > > >
> > >
> > > Yeah, that seems like the best plan forward.
> > >
> > > [sorry on reduced setup for the next 3 weeks, so I can't really debug
> > > the entire thing now.]
> > >
> > > Though, we should probably not annoy users unless we are trying to do
> > > something that won't be needed. I doubt that Saitek gamepad will ever
> > > call the faulty functions, so why putting an error in the logs when it's
> > > working fine?
> >
> > All right.
> >
> > Probably the best way to do this is simply to revert the commit that's
> > already applied and then merge a new patch to harden the core. Would
> > you like me to post the reversion patch or do you prefer to do it
> > yourself?
>
> Given that the faulty commit is on top of for-6.17/core, I can simply
> force push to the parent, and also force push the for-next branch. That
> should do the trick.
>
> Can you post your s32ton fix on top of that then?
Sure. Patch coming up shortly...
Alan Stern
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] HID: core: Harden s32ton() against conversion to 0 bits
2025-07-23 14:34 ` Alan Stern
@ 2025-07-23 14:37 ` Alan Stern
0 siblings, 0 replies; 27+ messages in thread
From: Alan Stern @ 2025-07-23 14:37 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: syzbot, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity. Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.
Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.com/
Tested-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Cc: stable@vger.kernel.org
---
The commit listed in the Fixes tag is not really the right one. But
code motion made tracking it back any further more difficult than I
wanted to deal with, so I stopped there. That commit is from 2006,
which is already far enough in the past.
drivers/hid/hid-core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: usb-devel/drivers/hid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/hid-core.c
+++ usb-devel/drivers/hid/hid-core.c
@@ -66,8 +66,12 @@ static s32 snto32(__u32 value, unsigned
static u32 s32ton(__s32 value, unsigned int n)
{
- s32 a = value >> (n - 1);
+ s32 a;
+ if (!value || !n)
+ return 0;
+
+ a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
return value & ((1 << n) - 1);
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: (subset) [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)
2025-07-15 19:29 ` Alan Stern
2025-07-15 19:50 ` syzbot
2025-07-18 16:08 ` (subset) " Benjamin Tissoires
@ 2025-07-25 11:46 ` Benjamin Tissoires
2 siblings, 0 replies; 27+ messages in thread
From: Benjamin Tissoires @ 2025-07-25 11:46 UTC (permalink / raw)
To: syzbot, Alan Stern
Cc: jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs
On Tue, 15 Jul 2025 15:29:25 -0400, Alan Stern wrote:
> On Mon, Jul 14, 2025 at 10:10:32AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: b4b4dbfa96de media: stk1160: use usb_alloc_noncoherent/usb..
> > 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=15a830f0580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=28729dff5d03ad1
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b63d677d63bcac06cf90
> > compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1614418c580000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1257dd82580000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/7301552ad828/disk-b4b4dbfa.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/c559b38fa1b6/vmlinux-b4b4dbfa.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/9c1da8b2a83f/bzImage-b4b4dbfa.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b63d677d63bcac06cf90@syzkaller.appspotmail.com
> >
> > usb 4-1: config 0 interface 0 altsetting 0 has 1 endpoint descriptor, different from the interface descriptor's value: 9
> > usb 4-1: New USB device found, idVendor=045e, idProduct=07da, bcdDevice= 0.00
> > usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > usb 4-1: config 0 descriptor??
> > microsoft 0003:045E:07DA.0001: ignoring exceeding usage max
> > microsoft 0003:045E:07DA.0001: unsupported Resolution Multiplier 0
> > ------------[ cut here ]------------
> > UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:69:16
> > shift exponent 4294967295 is too large for 32-bit type 'int'
> > CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.16.0-rc4-syzkaller-00314-gb4b4dbfa96de #0 PREEMPT(voluntary)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > <TASK>
> > __dump_stack lib/dump_stack.c:94 [inline]
> > dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
> > ubsan_epilogue lib/ubsan.c:233 [inline]
> > __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
> > s32ton.cold+0x37/0x9c drivers/hid/hid-core.c:69
> > hid_output_field drivers/hid/hid-core.c:1841 [inline]
> > hid_output_report+0x36f/0x4a0 drivers/hid/hid-core.c:1874
> > __hid_request+0x1e0/0x3c0 drivers/hid/hid-core.c:1987
> > hidinput_change_resolution_multipliers drivers/hid/hid-input.c:1950 [inline]
> > hidinput_connect+0x1ada/0x2bd0 drivers/hid/hid-input.c:2327
>
> [...]
Applied to hid/hid.git (for-6.17/core), thanks!
[1/1] HID: core: Harden s32ton() against conversion to 0 bits
https://git.kernel.org/hid/hid/c/a6b87bfc2ab5
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2025-07-25 11:46 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-14 17:10 [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) syzbot
2025-07-14 18:38 ` Alan Stern
2025-07-14 18:50 ` syzbot
2025-07-14 19:48 ` Alan Stern
2025-07-14 20:28 ` syzbot
2025-07-15 19:29 ` Alan Stern
2025-07-15 19:50 ` syzbot
2025-07-16 14:29 ` Alan Stern
2025-07-16 14:50 ` syzbot
2025-07-16 15:58 ` Alan Stern
2025-07-17 11:48 ` Benjamin Tissoires
2025-07-17 15:10 ` Alan Stern
2025-07-17 15:49 ` syzbot
2025-07-18 2:33 ` [PATCH] HID: core: Reject report fields with a size or count of 0 Alan Stern
2025-07-19 8:36 ` Benjamin Tissoires
2025-07-19 8:40 ` Benjamin Tissoires
2025-07-19 14:48 ` Alan Stern
2025-07-21 13:05 ` Benjamin Tissoires
2025-07-21 13:56 ` Alan Stern
2025-07-23 9:32 ` Benjamin Tissoires
2025-07-23 14:34 ` Alan Stern
2025-07-23 14:37 ` [PATCH] HID: core: Harden s32ton() against conversion to 0 bits Alan Stern
2025-07-21 14:37 ` [syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2) Alan Stern
2025-07-21 15:23 ` syzbot
2025-07-18 16:08 ` (subset) " Benjamin Tissoires
2025-07-23 9:36 ` Benjamin Tissoires
2025-07-25 11:46 ` Benjamin Tissoires
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).