kernel/git/stable/linux.git/drivers/media/usb, branch linux-5.4.y

media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()

2025-08-28T14:21:35+00:00

[ Upstream commit 7af160aea26c7dc9e6734d19306128cce156ec40 ] In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow. Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock. This possible bug was found by an experimental static analysis tool developed by our team. Fixes: 0f314f6c2e77 ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC driver") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han Signed-off-by: Hans Verkuil [ drivers/media/cec/usb/rainshadow/ => drivers/media/usb/rainshadow-cec/ ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: usbtv: Lock resolution while streaming

2025-08-28T14:21:31+00:00

commit 7e40e0bb778907b2441bff68d73c3eb6b6cd319f upstream. When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory. Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows. Fixes: 0e0fe3958fdd13d ("[media] usbtv: Add support for PAL video source") Cc: stable@vger.kernel.org Signed-off-by: Ludwig Disterhof Signed-off-by: Hans Verkuil [hverkuil: call vb2_is_busy instead of vb2_is_streaming] Signed-off-by: Greg Kroah-Hartman

media: gspca: Add bounds checking to firmware parser

2025-08-28T14:21:31+00:00

commit aef89c0b2417da79cb2062a95476288f9f203ab0 upstream. This sd_init() function reads the firmware. The firmware data holds a series of records and the function reads each record and sends the data to the device. The request_ihex_firmware() function calls ihex_validate_fw() which ensures that the total length of all the records won't read out of bounds of the fw->data[]. However, a potential issue is if there is a single very large record (larger than PAGE_SIZE) and that would result in memory corruption. Generally we trust the firmware, but it's always better to double check. Fixes: 49b61ec9b5af ("[media] gspca: Add new vicam subdriver") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Do not mark valid metadata as invalid

2025-08-28T14:21:30+00:00

commit bda2859bff0b9596a19648f3740c697ce4c71496 upstream. Currently, the driver performs a length check of the metadata buffer before the actual metadata size is known and before the metadata is decided to be copied. This results in valid metadata buffers being incorrectly marked as invalid. Move the length check to occur after the metadata size is determined and is decided to be copied. Cc: stable@vger.kernel.org Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node") Reviewed-by: Laurent Pinchart Reviewed-by: Hans de Goede Signed-off-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20250707-uvc-meta-v8-1-ed17f8b1218b@chromium.org Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()

2025-08-28T14:21:30+00:00

commit 782b6a718651eda3478b1824b37a8b3185d2740c upstream. The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format(). Signed-off-by: Youngjun Lee Reviewed-by: Laurent Pinchart Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Cc: stable@vger.kernel.org Reviewed-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20250610124107.37360-1-yjjuny.lee@samsung.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix bandwidth issue for Alcor camera

2025-08-28T14:21:28+00:00

[ Upstream commit 9764401bf6f8a20eb11c2e78470f20fee91a9ea7 ] Some broken device return wrong dwMaxPayloadTransferSize fields as follows: [ 218.632537] uvcvideo: Device requested 2752512 B/frame bandwidth. [ 218.632598] uvcvideo: No fast enough alt setting for requested bandwidth. When dwMaxPayloadTransferSize is greater than maxpsize, it will prevent the camera from starting. So use the bandwidth of maxpsize. Signed-off-by: chenchangcheng Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20250510061803.811433-1-ccc194101@163.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: usb: hdpvr: disable zero-length read messages

2025-08-28T14:21:28+00:00

[ Upstream commit b5ae5a79825ba8037b0be3ef677a24de8c063abf ] This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether. Signed-off-by: Wolfram Sang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: uvcvideo: Rollback non processed entities on error

2025-07-17T16:25:01+00:00

commit a70705d3c020d0d5c3ab6a5cc93e011ac35e7d48 upstream. If we fail to commit an entity, we need to restore the UVC_CTRL_DATA_BACKUP for the other uncommitted entities. Otherwise the control cache and the device would be out of sync. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Reported-by: Hans de Goede Closes: https://lore.kernel.org/linux-media/fe845e04-9fde-46ee-9763-a6f00867929a@redhat.com/ Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-3-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Send control events for partial succeeds

2025-07-17T16:25:01+00:00

commit 5c791467aea6277430da5f089b9b6c2a9d8a4af7 upstream. Today, when we are applying a change to entities A, B. If A succeeds and B fails the events for A are not sent. This change changes the code so the events for A are send right after they happen. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-2-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Return the number of processed controls

2025-07-17T16:25:00+00:00

commit ba4fafb02ad6a4eb2e00f861893b5db42ba54369 upstream. If we let know our callers that we have not done anything, they will be able to optimize their decisions. Cc: stable@kernel.org Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events") Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Message-ID: <20250224-uvc-data-backup-v2-1-de993ed9823b@chromium.org> Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Greg Kroah-Hartman