linux-stable.git/drivers/media/dvb-frontends, branch master Linux kernel stable tree media: dvb-frontends/helene: Rename priv variable 2026-07-10T12:17:56+00:00 Ricardo Ribalda ribalda@chromium.org 2026-06-29T11:30:47+00:00 5b8af852cd0303fc2faafd80d76ca7b19d15ca54 Coccinelle triggers a false positive where it thinks that the priv variable in helene_attach_s and helene_attach is the same variable as helene_probe. This is due to a bad heuristic in cocci. We have reported it to cocci, but until/if this is fixed, renaming a local variable is a good compromise to fix this warning: ./dvb-frontends/helene.c:1049:2-7: WARNING: invalid free of devm_ allocated data ./dvb-frontends/helene.c:1013:2-7: WARNING: invalid free of devm_ allocated data Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
Coccinelle triggers a false positive where it thinks that the priv
variable in helene_attach_s and helene_attach is the same variable as
helene_probe. This is due to a bad heuristic in cocci.

We have reported it to cocci, but until/if this is fixed, renaming a
local variable is a good compromise to fix this warning:

./dvb-frontends/helene.c:1049:2-7: WARNING: invalid free of devm_ allocated data
./dvb-frontends/helene.c:1013:2-7: WARNING: invalid free of devm_ allocated data

Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure 2026-07-10T07:53:50+00:00 Valery Borovsky vebohr@gmail.com 2026-05-23T16:53:58+00:00 fe50cdaebf12cd32ff9a44d92bfd6fbc2300dbd4 rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky <vebohr@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(),
rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and
shares a single err: label that only unlocks the mutex and returns.
When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs()
itself returns -ENOMEM after alloc_stream_bufs() has already succeeded,
the URBs and/or the coherent DMA stream buffers stay allocated while
streaming reports failure to vb2. Two latent defects follow on the next
VIDIOC_STREAMON:

1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num
   to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently
   leaking the coherent DMA memory allocated by the previous attempt.

2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only
   increments it. After a second successful pass urbs_initialized can
   exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks
   from urbs_initialized - 1 down to 0 and reads past the end of
   dev->urb_list[], passing garbage pointers to usb_free_urb().

Mirror the teardown that stop_streaming() already performs: on the error
path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs()
before unlocking. Both helpers are idempotent (free_urbs kills and zeros
urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the
buf_num counter), so partial-failure paths and the no-allocation paths
remain safe.

Issue identified by automated review of the INV-003 series at
https://sashiko.dev/

Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak 2026-07-10T07:53:50+00:00 Valery Borovsky vebohr@gmail.com 2026-05-23T16:53:37+00:00 dabb047c62668f280998e29117c55e41aabac336 rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Suggested-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Valery Borovsky <vebohr@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to
NULL before any pending streaming teardown has run. When user space
later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming()
which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases
each coherent buffer with:

    usb_free_coherent(dev->udev, dev->buf_size,
                      dev->buf_list[dev->buf_num],
                      dev->dma_addr[dev->buf_num]);

usb_free_coherent() returns immediately when its dev argument is NULL,
so every DMA stream buffer that was live at disconnect is silently
leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the
device for the same reason.

The rtl2832_sdr driver uses vb2_fop_release() in its file_operations,
so replace video_unregister_device(&dev->vdev) with
vb2_video_unregister_device(&dev->vdev) and move it before clearing
dev->udev. vb2_video_unregister_device() releases the vb2 queue, which
synchronously runs rtl2832_sdr_stop_streaming() if streaming is active,
so URBs and coherent DMA stream buffers are freed while dev->udev is
still valid.

vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock)
internally, and stop_streaming() locks v4l2_lock, so the previous outer
mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair
around the unregister sequence would self-deadlock and has been removed.
A short v4l2_lock critical section around dev->udev = NULL remains so
any ioctl path that still holds the file descriptor sees coherent state.

Issue identified by automated review of the INV-003 series at
https://sashiko.dev/

Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Suggested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: Use named initializers for arrays of i2c_device_data 2026-05-20T07:03:40+00:00 Uwe Kleine-König (The Capable Hub) u.kleine-koenig@baylibre.com 2026-05-15T16:15:28+00:00 2958d579ffb13571c9788d741e6115dc917b05a4 While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching all these arrays, unify usage of whitespace and commas. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.

The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.

While touching all these arrays, unify usage of whitespace and commas.

This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: rtl2832_sdr: Return queued buffers on start_streaming() failure 2026-05-12T07:39:02+00:00 Valery Borovsky vebohr@gmail.com 2026-05-11T17:12:09+00:00 33ca0aab6f4bd90921fc1395478f38f72c4d19af The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here. Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky <vebohr@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming().  If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.

rtl2832_sdr_start_streaming() had multiple error paths that hit this
trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six
`goto err` paths covering subdev s_power, tuner setup, ADC setup,
stream-buffer allocation, urb allocation, and urb submission failures.
None of them returned the queued buffers.

The original function had no distinct success exit and fell straight
through into the err label, which previously only did mutex_unlock and
"return ret".  Adding queued-buffer cleanup at err must therefore be
paired with an explicit success return; otherwise every successful
start would also drain the buffer queue and kill streaming.  Add that
success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err
label and before each early return.

The cleanup helper takes a vb2_buffer_state argument so that the
start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as
expected by userspace on start_streaming failure) while stop_streaming
keeps its existing VB2_BUF_STATE_ERROR semantics.

This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").

The err label still does not roll back power_ctrl(), frontend_ctrl(),
the POWER_ON flag, or stream/URB allocations that may have happened
before the failing step.  Those are pre-existing leaks of a different
class and are not addressed here.

Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: rtl2832: fix use-after-free in rtl2832_remove() 2026-05-06T07:05:56+00:00 Deepanshu Kartikey kartikey406@gmail.com 2026-04-22T14:47:34+00:00 680daf40a82d483949f87f0d8f98639dc47e610c cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final. Fixes: cddcc40b1b15 ("[media] rtl2832: convert to use an explicit i2c mux core") Cc: stable@vger.kernel.org Reported-by: syzbot+019ced393ab913002b75@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=019ced393ab913002b75 Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
cancel_delayed_work_sync() is called before i2c_mux_del_adapters()
in rtl2832_remove(). While the cancel waits for any running instance
of i2c_gate_work to finish, it does not prevent the timer from being
rescheduled by a concurrent thread.

During probe, the r820t_attach() call attempts I2C transfers through
the mux adapter. These transfers go through i2c_mux_master_xfer(),
which calls rtl2832_deselect() after the transfer completes,
rescheduling i2c_gate_work via schedule_delayed_work(). If this
transfer is still in flight when rtl2832_remove() runs,
rtl2832_deselect() can reschedule i2c_gate_work after it has been
cancelled, causing a use-after-free when kfree(dev) is called.

Fix this by calling i2c_mux_del_adapters() before
cancel_delayed_work_sync(). Once the mux adapter is unregistered, no
new I2C transfers can go through it, so rtl2832_deselect() can no
longer reschedule i2c_gate_work. The subsequent
cancel_delayed_work_sync() is then guaranteed to be final.

Fixes: cddcc40b1b15 ("[media] rtl2832: convert to use an explicit i2c mux core")
Cc: stable@vger.kernel.org
Reported-by: syzbot+019ced393ab913002b75@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=019ced393ab913002b75
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: m88ds3103: Implement 3103c chip support 2026-03-25T17:27:25+00:00 Bradford Love brad@nextdimension.cc 2026-03-17T20:57:47+00:00 a05d61fe0a9bf2646a152d494498e42b0b630a58 Hauppauge 416e products have moved to using the 3103C satellite demod. This demod behaves mostly like a 3103b, but has different initialization, clocking, and lock operations. This Linux code was reverse egineered entirely using a Windows reference driver. Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> [hverkuil: fix a few minor checkpatch issues] [hverkuil: fixed two minor sparse issues] 
Hauppauge 416e products have moved to using the 3103C satellite
demod. This demod behaves mostly like a 3103b, but has
different initialization, clocking, and lock operations.

This Linux code was reverse egineered entirely
using a Windows reference driver.

Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
[hverkuil: fix a few minor checkpatch issues]
[hverkuil: fixed two minor sparse issues]
media: au0828: Add new Hauppauge HVR1265 and ImpactVCB-e 2026-03-17T09:50:19+00:00 Bradford Love brad@nextdimension.cc 2026-03-12T21:35:30+00:00 5e521401d058b4b4bce9689e5897e286f1d4d8b0 New HVR1265 and ImpactVCB-e devices are PCIe baords with USB controller and essentially embedded Hauppauge 950Q. HVR1265 - digital+analog TV, S-Video, and audio inputs ImpactVCB-e - Composite, S-Video, and audio inputs This also fixes AU8522_COMPOSITE_CH4, which was missing from video routing. Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
New HVR1265 and ImpactVCB-e devices are PCIe baords
with USB controller and essentially embedded
Hauppauge 950Q.

HVR1265 - digital+analog TV, S-Video, and audio inputs
ImpactVCB-e - Composite, S-Video, and audio inputs

This also fixes AU8522_COMPOSITE_CH4, which was missing
from video routing.

Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: si2168: fw 4.0-11 loses warm state during sleep 2026-03-17T09:50:19+00:00 Bradford Love brad@nextdimension.cc 2026-03-12T21:35:28+00:00 57c3c67fce95ab0d449d3f6ae339621fcb61080e Ignoring version 4.0-11 firmware leads to non functional devices after sleep on all Hauppauge DVB devices containing the si2168 and firmware version 4.0-11. Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
Ignoring version 4.0-11 firmware leads to non functional devices
after sleep on all Hauppauge DVB devices containing the si2168 and
firmware version 4.0-11.

Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: si2168: Fix i2c command timeout on embedded platforms 2026-03-17T09:50:19+00:00 Bradford Love brad@nextdimension.cc 2026-03-12T21:35:27+00:00 3c414622fe4bcedc48305bfe2170ae13119fc331 On many embedded platforms i2c responses through USB are not returned as quickly, plus constantly banging on the i2c master receive essentially deadlocks the driver. Inserting a 3ms delay between i2c receive calls and extending the timeout fixes all tested platforms. Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
On many embedded platforms i2c responses through USB are not returned
as quickly, plus constantly banging on the i2c master receive essentially
deadlocks the driver. Inserting a 3ms delay between i2c receive calls
and extending the timeout fixes all tested platforms.

Signed-off-by: Bradford Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>