[syzbot] [input?] [usb?] UBSAN: shift-out-of-bounds in s32ton (2)

[syzbot]

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+b63d67...@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 syzk...@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

[Alan Stern]

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/hid.git c2ca42f190b6

[syzbot]

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.

[Alan Stern]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git c2ca42f190b6

[syzbot]

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

[Alan Stern]

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]);
}

[syzbot]

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

[Alan Stern]

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;

[syzbot]

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

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

[Alan Stern]

Benjamin:

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

[Benjamin Tissoires]

Hi Alan,

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

[Alan Stern]

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_

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+b63d67...@syzkaller.appspotmail.com
Tested-by: syzbot+b63d67...@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.

[Alan Stern]

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 <st...@rowland.harvard.edu>
Reported-by: syzbot+b63d67...@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/68753a08.050a022...@google.com/
Tested-by: syzbot+b63d67...@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Cc: sta...@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(-)

[Benjamin Tissoires]

> [...]

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 <ben...@kernel.org>

[Benjamin Tissoires]

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

[Benjamin Tissoires]

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

[Alan Stern]

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 <st...@rowland.harvard.edu>
> > Reported-by: syzbot+b63d67...@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-usb/68753a08.050a022...@google.com/
> > Tested-by: syzbot+b63d67...@syzkaller.appspotmail.com
> > Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
> > Cc: sta...@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

[Benjamin Tissoires]

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

[Alan Stern]

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

[Alan Stern]

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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+b63d67...@syzkaller.appspotmail.com
Tested-by: syzbot+b63d67...@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

[Benjamin Tissoires]

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

[Benjamin Tissoires]

FTR, the patch has been dropped from for-next, it broke existing
devices. A better patch is being worked on.

Cheers,
Benjamin

[Alan Stern]

Sure. Patch coming up shortly...

Alan Stern

[Alan Stern]

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 <st...@rowland.harvard.edu>
Reported-by: syzbot+b63d67...@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/68753a08.050a022...@google.com/
Tested-by: syzbot+b63d67...@syzkaller.appspotmail.com
Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split")
Cc: sta...@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

[Benjamin Tissoires]

On Tue, 15 Jul 2025 15:29:25 -0400, Alan Stern wrote:

> [...]

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