<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/media/platform/vivid, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-07-17T16:24:52Z</updated>
<entry>
<title>media: vivid: Change the siize of the composing</title>
<updated>2025-07-17T16:24:52Z</updated>
<author>
<name>Denis Arefev</name>
</author>
<published>2025-04-15T08:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57597d8db5bbda618ba2145b7e8a7e6f01b6a27e'/>
<id>urn:sha1:57597d8db5bbda618ba2145b7e8a7e6f01b6a27e</id>
<content type='text'>
[ Upstream commit f83ac8d30c43fd902af7c84c480f216157b60ef0 ]

syzkaller found a bug:

BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304

CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014

Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:489
 kasan_report+0x143/0x180 mm/kasan/report.c:602
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]
 tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline]
 vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629
 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767
 kthread+0x7a9/0x920 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;

The composition size cannot be larger than the size of fmt_cap_rect.
So execute v4l2_rect_map_inside() even if has_compose_cap == 0.

Fixes: 94a7ad928346 ("media: vivid: fix compose size exceed boundary")
Cc: stable@vger.kernel.org
Reported-by: syzbot+365005005522b70a36f2@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=8ed8e8cc30cbe0d86c9a25bd1d6a5775129b8ea3
Signed-off-by: Denis Arefev &lt;arefev@swemel.ru&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil@xs4all.nl&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: avoid integer overflow</title>
<updated>2023-11-28T16:50:15Z</updated>
<author>
<name>Hans Verkuil</name>
</author>
<published>2023-09-23T15:20:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a251e20a2cbe06325e02dee79ed79855dc2451a3'/>
<id>urn:sha1:a251e20a2cbe06325e02dee79ed79855dc2451a3</id>
<content type='text'>
[ Upstream commit 4567ebf8e8f9546b373e78e3b7d584cc30b62028 ]

Fixes these compiler warnings:

drivers/media/test-drivers/vivid/vivid-rds-gen.c: In function 'vivid_rds_gen_fill':
drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:56: warning: '.' directive output may be truncated writing 1 byte into a region of size between 0 and 3 [-Wformat-truncation=]
  147 |         snprintf(rds-&gt;psname, sizeof(rds-&gt;psname), "%6d.%1d",
      |                                                        ^
drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:52: note: directive argument in the range [0, 9]
  147 |         snprintf(rds-&gt;psname, sizeof(rds-&gt;psname), "%6d.%1d",
      |                                                    ^~~~~~~~~
drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:9: note: 'snprintf' output between 9 and 12 bytes into a destination of size 9
  147 |         snprintf(rds-&gt;psname, sizeof(rds-&gt;psname), "%6d.%1d",
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  148 |                  freq / 16, ((freq &amp; 0xf) * 10) / 16);
      |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: fix compose size exceed boundary</title>
<updated>2023-01-18T10:41:01Z</updated>
<author>
<name>Liu Shixin</name>
</author>
<published>2022-10-27T12:38:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=54f259906039dbfe46c550011409fa16f72370f6'/>
<id>urn:sha1:54f259906039dbfe46c550011409fa16f72370f6</id>
<content type='text'>
[ Upstream commit 94a7ad9283464b75b12516c5512541d467cefcf8 ]

syzkaller found a bug:

 BUG: unable to handle page fault for address: ffffc9000a3b1000
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
 RIP: 0010:memcpy_erms+0x6/0x10
[...]
 Call Trace:
  &lt;TASK&gt;
  ? tpg_fill_plane_buffer+0x856/0x15b0
  vivid_fillbuff+0x8ac/0x1110
  vivid_thread_vid_cap_tick+0x361/0xc90
  vivid_thread_vid_cap+0x21a/0x3a0
  kthread+0x143/0x180
  ret_from_fork+0x1f/0x30
  &lt;/TASK&gt;

This is because we forget to check boundary after adjust compose-&gt;height
int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
for this case.

Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts")
Signed-off-by: Liu Shixin &lt;liushixin2@huawei.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: dev-&gt;bitmap_cap wasn't freed in all cases</title>
<updated>2022-11-03T14:56:55Z</updated>
<author>
<name>Hans Verkuil</name>
</author>
<published>2022-10-13T14:18:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d8f479c777b413ba42c63e1a5ce6eee3d25b6714'/>
<id>urn:sha1:d8f479c777b413ba42c63e1a5ce6eee3d25b6714</id>
<content type='text'>
[ Upstream commit 1f65ea411cc7b6ff128d82a3493d7b5648054e6f ]

Whenever the compose width/height values change, the dev-&gt;bitmap_cap
vmalloc'ed array must be freed and dev-&gt;bitmap_cap set to NULL.

This was done in some places, but not all. This is only an issue if
overlay support is enabled and the bitmap clipping is used.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts)
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: s_fbuf: add more sanity checks</title>
<updated>2022-11-03T14:56:55Z</updated>
<author>
<name>Hans Verkuil</name>
</author>
<published>2022-10-12T14:32:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9d6870949c2c294eff8e7db3d3307957416481e1'/>
<id>urn:sha1:9d6870949c2c294eff8e7db3d3307957416481e1</id>
<content type='text'>
[ Upstream commit f8bcaf714abfc94818dff8c0db84d750433984f4 ]

VIDIOC_S_FBUF is by definition a scary ioctl, which is why only root
can use it. But at least check if the framebuffer parameters match that
of one of the framebuffer created by vivid, and reject anything else.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts)
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: fix assignment of dev-&gt;fbuf_out_flags</title>
<updated>2021-05-14T07:44:23Z</updated>
<author>
<name>Colin Ian King</name>
</author>
<published>2021-02-25T15:43:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=75c6252e863093f5fbe1794533f6aa69279a6dbb'/>
<id>urn:sha1:75c6252e863093f5fbe1794533f6aa69279a6dbb</id>
<content type='text'>
[ Upstream commit 5cde22fcc7271812a7944c47b40100df15908358 ]

Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise
mask and the following statement should be bit-wise or'ing in the new flag
bits but instead is making a direct assignment.  Fix this by using the |=
operator rather than an assignment.

Addresses-Coverity: ("Unused value")

Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: update EDID</title>
<updated>2021-05-11T12:04:10Z</updated>
<author>
<name>Hans Verkuil</name>
</author>
<published>2021-03-25T07:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=330753d38f26722612f60e2d9fd4d33159fa14a9'/>
<id>urn:sha1:330753d38f26722612f60e2d9fd4d33159fa14a9</id>
<content type='text'>
[ Upstream commit 443ec4bbc6116f6f492a7a1282bfd8422c862158 ]

The EDID had a few mistakes as reported by edid-decode:

Block 1, CTA-861 Extension Block:
  Video Data Block: For improved preferred timing interoperability, set 'Native detailed modes' to 1.
  Video Capability Data Block: S_PT is equal to S_IT and S_CE, so should be set to 0 instead.

Fixed those.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: media_device_cleanup was called too early</title>
<updated>2019-12-31T15:44:44Z</updated>
<author>
<name>Hans Verkuil</name>
</author>
<published>2019-11-02T17:35:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=12d8deb5213ea8a566e9c4b463233e92abaded04'/>
<id>urn:sha1:12d8deb5213ea8a566e9c4b463233e92abaded04</id>
<content type='text'>
[ Upstream commit 8ffd573c25e5fac1daeeffc592e2ed6bc6a3d947 ]

Running the contrib/test/test-media script in v4l-utils with the vivid argument
will cause this kernel warning:

[  104.748720] videodev: v4l2_release
[  104.748731] ------------[ cut here ]------------
[  104.748750] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
[  104.748790] WARNING: CPU: 6 PID: 1823 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10
[  104.748800] Modules linked in: rc_cec vivid v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx
[  104.748845] CPU: 6 PID: 1823 Comm: sleep Not tainted 5.4.0-rc1-test-no #150
[  104.748853] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019
[  104.748867] RIP: 0010:__mutex_lock+0x919/0xc10
[  104.748878] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb
f7 fe &lt;0f&gt; 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7
[  104.748886] RSP: 0018:ffff88811a357b80 EFLAGS: 00010286
[  104.748895] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  104.748902] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed102346af62
[  104.748910] RBP: ffff88811a357cf0 R08: ffffffff81217c91 R09: fffffbfff061c271
[  104.748917] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff8881a46103c0
[  104.748924] R13: 0000000000000000 R14: ffff8881a4614f90 R15: ffff8881a46153d0
[  104.748933] FS:  0000000000000000(0000) GS:ffff8881b6780000(0000) knlGS:0000000000000000
[  104.748940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  104.748949] CR2: 00007f163fc9ca20 CR3: 0000000003013004 CR4: 00000000001606e0
[  104.749036] Call Trace:
[  104.749051]  ? _raw_spin_unlock+0x1f/0x30
[  104.749067]  ? llist_add_batch+0x33/0x50
[  104.749081]  ? tick_nohz_tick_stopped+0x19/0x30
[  104.749130]  ? v4l2_release.cold+0x6c/0xd6 [videodev]
[  104.749143]  ? mutex_lock_io_nested+0xb80/0xb80
[  104.749153]  ? vprintk_emit+0xf2/0x220
[  104.749191]  ? vivid_req_validate+0x40/0x40 [vivid]
[  104.749201]  ? printk+0xad/0xde
[  104.749211]  ? kmsg_dump_rewind_nolock+0x54/0x54
[  104.749226]  ? locks_remove_file+0x78/0x2b0
[  104.749248]  ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170
[  104.749281]  ? vivid_req_validate+0x40/0x40 [vivid]
[  104.749321]  ? v4l2_release.cold+0x6c/0xd6 [videodev]
[  104.749361]  v4l2_release.cold+0x6c/0xd6 [videodev]
[  104.749378]  __fput+0x15a/0x390
[  104.749393]  task_work_run+0xb2/0xe0
[  104.749407]  do_exit+0x4d0/0x1200
[  104.749422]  ? do_user_addr_fault+0x367/0x610
[  104.749431]  ? release_task+0x990/0x990
[  104.749449]  ? rwsem_spin_on_owner+0x170/0x170
[  104.749463]  ? vmacache_find+0xb2/0x100
[  104.749476]  do_group_exit+0x85/0x130
[  104.749487]  __x64_sys_exit_group+0x23/0x30
[  104.749500]  do_syscall_64+0x5e/0x1c0
[  104.749511]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  104.749520] RIP: 0033:0x7f163fc5c9d6
[  104.749536] Code: Bad RIP value.
[  104.749543] RSP: 002b:00007ffe6f3bec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[  104.749553] RAX: ffffffffffffffda RBX: 00007f163fd4d760 RCX: 00007f163fc5c9d6
[  104.749560] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[  104.749567] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[  104.749574] R10: 00007ffe6f3beb24 R11: 0000000000000246 R12: 00007f163fd4d760
[  104.749581] R13: 0000000000000002 R14: 00007f163fd56428 R15: 0000000000000000
[  104.749597] ---[ end trace 66f20f73fc0daf79 ]---

This is caused by media_device_cleanup() which destroys
v4l2_dev-&gt;mdev-&gt;req_queue_mutex. But v4l2_release() tries to lock
that mutex after media_device_cleanup() is called.

By moving media_device_cleanup() to the v4l2_device's release function it is
guaranteed that the mutex is valid whenever v4l2_release is called.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: vivid: Fix wrong locking that causes race conditions on streaming stop</title>
<updated>2019-11-29T09:10:04Z</updated>
<author>
<name>Alexander Popov</name>
</author>
<published>2019-11-03T22:17:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5aa7ad7e991e6cb0c3a1825dbe7f78c2a8116ccc'/>
<id>urn:sha1:5aa7ad7e991e6cb0c3a1825dbe7f78c2a8116ccc</id>
<content type='text'>
commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream.

There is the same incorrect approach to locking implemented in
vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and
sdr_cap_stop_streaming().

These functions are called during streaming stopping with vivid_dev.mutex
locked. And they all do the same mistake while stopping their kthreads,
which need to lock this mutex as well. See the example from
vivid_stop_generating_vid_cap():
  /* shutdown control thread */
  vivid_grab_controls(dev, false);
  mutex_unlock(&amp;dev-&gt;mutex);
  kthread_stop(dev-&gt;kthread_vid_cap);
  dev-&gt;kthread_vid_cap = NULL;
  mutex_lock(&amp;dev-&gt;mutex);

But when this mutex is unlocked, another vb2_fop_read() can lock it
instead of vivid_thread_vid_cap() and manipulate the buffer queue.
That causes a use-after-free access later.

To fix those issues let's:
  1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(),
vivid_stop_generating_vid_out() and sdr_cap_stop_streaming();
  2. use mutex_trylock() with schedule_timeout_uninterruptible() in
the loops of the vivid kthread handlers.

Signed-off-by: Alexander Popov &lt;alex.popov@linux.com&gt;
Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Tested-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Cc: &lt;stable@vger.kernel.org&gt;      # for v3.18 and up
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: vivid: Set vid_cap_streaming and vid_out_streaming to true</title>
<updated>2019-11-29T09:10:03Z</updated>
<author>
<name>Vandana BN</name>
</author>
<published>2019-09-09T09:43:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=92edb64da943463aa19dd7997b943cf548500ea2'/>
<id>urn:sha1:92edb64da943463aa19dd7997b943cf548500ea2</id>
<content type='text'>
commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream.

When vbi stream is started, followed by video streaming,
the vid_cap_streaming and vid_out_streaming were not being set to true,
which would cause the video stream to stop when vbi stream is stopped.
This patch allows to set vid_cap_streaming and vid_out_streaming to true.
According to Hans Verkuil it appears that these 'if (dev-&gt;kthread_vid_cap)'
checks are a left-over from the original vivid development and should never
have been there.

Signed-off-by: Vandana BN &lt;bnvandana@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;      # for v3.18 and up
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
