kernel/drivers/usb/class/usbtmc.c, branch linux-6.9.y

USB: usbtmc: Fix direction for 0-length ioctl control messages

2023-05-13T08:25:49Z

The syzbot fuzzer found a problem in the usbtmc driver: When a user submits an ioctl for a 0-length control transfer, the driver does not check that the direction is set to OUT: ------------[ cut here ]------------ usb 3-1: BOGUS control dir, pipe 80000b80 doesn't match bRequestType fd WARNING: CPU: 0 PID: 5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 0 PID: 5100 Comm: syz-executor428 Not tainted 6.3.0-syzkaller-12049-g58390c8ce1bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Code: 7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41 RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8880789e9058 RCX: 0000000000000000 RDX: ffff888029593b80 RSI: ffffffff814c1447 RDI: 0000000000000001 RBP: ffff88801ea742f8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528 R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100 FS: 0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline] usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097 To fix this, we must override the direction in the bRequestType field of the control request structure when the length is 0. Reported-and-tested-by: syzbot+ce77725b89b7bd52425c@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/linux-usb/000000000000716a3705f9adb8ee@google.com/ CC: Link: https://lore.kernel.org/r/ede1ee02-b718-49e7-a44c-51339fec706b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

usb: usbtmc: Fix bug in pipe direction for control transfers

2022-03-15T17:45:31Z

The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. CC: Reported-and-tested-by: syzbot+a48e3d1a875240cab5de@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/YiEsYTPEE6lOCOA5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

USB: usbtmc: Fix RCU stall warning

2021-07-27T13:52:37Z

rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000 softirq=25390/25392 fqs=3 (t=12164 jiffies g=31645 q=43226) rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:R running task ........... usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: usb_submit_urb failed: -19 The function usbtmc_interrupt() resubmits urbs when the error status of an urb is -EPROTO. In systems using the dummy_hcd usb controller this can result in endless interrupt loops when the usbtmc device is disconnected from the host system. Since host controller drivers already try to recover from transmission errors, there is no need to resubmit the urb or try other solutions to repair the error situation. In case of errors the INT pipe just stops to wait for further packets. Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation") Cc: stable@vger.kernel.org Reported-by: syzbot+e2eae5639e7203360018@syzkaller.appspotmail.com Signed-off-by: Qiang.zhang Acked-by: Guido Kiener Link: https://lore.kernel.org/r/20210723004334.458930-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman

USB: usbtmc: Bump USBTMC_API_VERSION value

2020-12-28T14:50:30Z

The previous patches in this series have changed the behaviour of the driver and added new calls. Tested-by: Jian-Wei Wu Reviewed-by: Guido Kiener Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20201215155621.9592-5-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: usbtmc: Add separate USBTMC_IOCTL_GET_SRQ_STB

2020-12-28T14:50:30Z

This new ioctl only returns the status byte (STB) that was originally sent by the device due to a service request (SRQ) condition. This ioctl checks the srq_asserted bit of the associated file descriptor. If set, the srq_asserted bit is reset and the cached STB with original SRQ information is returned. Otherwise the ioctl returns the error code ENOMSG. This ioctl is useful to support non USBTMC-488 compliant devices. Time sensitive applications can read the cached STB without incurring the cost of an urb transaction over the bus. Tested-by: Jian-Wei Wu Reviewed-by: Guido Kiener Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20201215155621.9592-4-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: usbtmc: Add USBTMC_IOCTL_GET_STB

2020-12-28T14:50:30Z

This new ioctl reads the status byte (STB) from the device and returns the STB unmodified to the application. The srq_asserted bit is not taken into account and not changed. This ioctl is useful to support non USBTMC-488 compliant devices. Tested-by: Jian-Wei Wu Reviewed-by: Guido Kiener Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20201215155621.9592-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: usbtmc: Fix reading stale status byte

2020-12-28T14:50:30Z

The ioctl USBTMC488_IOCTL_READ_STB either returns a cached status byte (STB) sent by the device due to a service request (SRQ) condition or the STB obtained from a query to the device with a READ_STATUS_BYTE control message. When the query is interrupted by an SRQ message on the interrupt pipe, the ioctl still returns the requested STB while the STB of the out-of-band SRQ message is cached for the next call of this ioctl. However the cached SRQ STB represents a state that was previous to the last returned STB. Furthermore the cached SRQ STB can be stale and not reflect the current state of the device. The fixed ioctl now always reads the STB from the device and if the associated file descriptor has the srq_asserted bit set it ors in the RQS bit to the returned STB and clears the srq_asserted bit conformant to subclass USB488 devices. Tested-by: Jian-Wei Wu Reviewed-by: Guido Kiener Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20201215155621.9592-2-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: Use fallthrough pseudo-keyword

2020-07-10T06:55:17Z

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20200707195607.GA4198@embeddedor Signed-off-by: Greg Kroah-Hartman

usb: class: usbtmc: File headers are not good candidates for kerneldoc

2020-07-03T08:18:40Z

Demote usbtmc's file header to a standard comment block. Fixes the following W=1 kernel build warning(s): drivers/usb/class/usbtmc.c:11: warning: Function parameter or member 'fmt' not described in 'pr_fmt' Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200702144625.2533530-30-lee.jones@linaro.org Signed-off-by: Greg Kroah-Hartman

compat_ioctl: move more drivers to compat_ptr_ioctl

2019-10-23T15:23:44Z

The .ioctl and .compat_ioctl file operations have the same prototype so they can both point to the same function, which works great almost all the time when all the commands are compatible. One exception is the s390 architecture, where a compat pointer is only 31 bit wide, and converting it into a 64-bit pointer requires calling compat_ptr(). Most drivers here will never run in s390, but since we now have a generic helper for it, it's easy enough to use it consistently. I double-checked all these drivers to ensure that all ioctl arguments are used as pointers or are ignored, but are not interpreted as integer values. Acked-by: Jason Gunthorpe Acked-by: Daniel Vetter Acked-by: Mauro Carvalho Chehab Acked-by: Greg Kroah-Hartman Acked-by: David Sterba Acked-by: Darren Hart (VMware) Acked-by: Jonathan Cameron Acked-by: Bjorn Andersson Acked-by: Dan Williams Signed-off-by: Arnd Bergmann