kernel.git/drivers/media/rc, branch linux-6.17.y

media: redrat3: use int type to store negative error codes

2025-11-13T20:37:19Z

[ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ] Change "ret" from u8 to int type in redrat3_enable_detector() to store negative error codes or zero returned by redrat3_send_cmd() and usb_submit_urb() - this better aligns with the coding standards and maintains code consistency. No effect on runtime. Signed-off-by: Qianfeng Rong Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: imon: make send_packet() more robust

2025-11-13T20:37:02Z

[ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ] syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds. Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1] Link: https://lkml.kernel.org/r/d6da6709-d799-4be3-a695-850bddd6eb24@rowland.harvard.edu [2] Signed-off-by: Tetsuo Handa Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: lirc: Fix error handling in lirc_register()

2025-10-19T14:37:22Z

commit 4f4098c57e139ad972154077fb45c3e3141555dd upstream. When cdev_device_add() failed, calling put_device() to explicitly release dev->lirc_dev. Otherwise, it could cause the fault of the reference count. Found by code review. Cc: stable@vger.kernel.org Fixes: a6ddd4fecbb0 ("media: lirc: remove last remnants of lirc kapi") Signed-off-by: Ma Ke Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: rc: fix races with imon_disconnect()

2025-10-06T09:20:05Z

commit fa0f61cc1d828178aa921475a9b786e7fbb65ccb upstream. Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465 CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer. Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1) ... while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAF Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present. Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations. Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Reported-by: syzbot+f1a69784f6efe748c3bf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1a69784f6efe748c3bf Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Cc: stable@vger.kernel.org Signed-off-by: Larshin Sergey Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: Remove redundant pm_runtime_mark_last_busy() calls

2025-08-18T07:55:08Z

pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Reviewed-by: Laurent Pinchart Acked-by: Thierry Reding (tegra-vde/h264.c) Acked-by: Tommaso Merciai (alvium-csi2.c) Reviewed-by: Dikshita Agarwal (iris_hfi_queue.c) Reviewed-by: Sean Young Acked-by: Dave Stevenson (imx219.c) Acked-by: Benjamin Mugnier Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil

media: rc: ir-spi: avoid overflow in multiplication

2025-06-23T10:11:04Z

Switch to u64 arithmetic and use DIV_ROUND_CLOSEST_ULL() to avoid the overflow. buffer[i] is unsigned int and is limited by the lirc core to IR_MAX_DURATION, which is 500000. idata->freq is u32, which has a max value of 0xFFFFFFFF. In the case where buffer[i] is 500000, idata->freq overflows the u32 multiplication for any values >= 8590. 0xFFFFFFFF / 500000 ~= 8589 By casting buffer[i] to u64, idata->freq can be any u32 value without overflowing the multiplication. 0xFFFFFFFFFFFFFFFF / 500000 ~= 36893488147419 (> 4294967295) The result of the final operation will fit back into the unsigned int limits without any issues. 500000 * 0xFFFFFFFF / 1000000 = 0x80000000 (< 0xFFFFFFFF) Signed-off-by: Cosmin Tanislav Signed-off-by: Sean Young Signed-off-by: Hans Verkuil

media: rc: ir-spi: constrain carrier frequency

2025-06-23T10:11:04Z

Carrier frequency is currently unconstrained, allowing the SPI transfer to be allocated and filled only for it to be later rejected by the SPI controller since the frequency is too large. Add a check to constrain the carrier frequency inside ir_spi_set_tx_carrier(). Also, move the number of bits per pulse to a macro since it is not used in multiple places. Signed-off-by: Cosmin Tanislav Signed-off-by: Sean Young Signed-off-by: Hans Verkuil

media: rc: ir-spi: allocate buffer dynamically

2025-06-23T10:11:04Z

Replace the static transmit buffer with a dynamically allocated one, removing the limit imposed on the number of pulses to transmit. Calculate the number of pulses for each duration in the received buffer ahead of time, while also adding up the total pulses, to be able to allocate a buffer that perfectly fits the total number of pulses, then populate it. Signed-off-by: Cosmin Tanislav Signed-off-by: Sean Young Signed-off-by: Hans Verkuil

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37Z

Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

media: rc: add keymap for Hauppauge Credit Card RC

2025-04-30T07:35:24Z

Add keymap for the black Hauppauge Credit Card Remote Control. Signed-off-by: Petja Patjas Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab