Hi Ricard,
Le vendredi 18 juin 2021 à 14:29 +0200, Ricardo Ribalda a écrit :
> All the entities must have a unique name. We can have a descriptive and
> unique name by appending the function and the entity->id.
Thanks for your work. The only issue is that unfortunately this change cause an
important regression for users. All UVC cameras in all UIs seems to no longer
include any information about the camera. As an example, I have two cameras on
my system and Firefox, Chrome, Cheese, Zoom and MS Team all agree that my camera
are now:
Video Capture 4
Video Capture 5
Previously they would be shown as something like:
StreamCam
Integrated
We should probably revert this change quickly before it get deployed more
widely, I have notice the backport being sent for 5.4, 5.10 and 5.14. I'm using
5.15 shipped by Fedora team.
As a proper solution, maybe I could suggest to keep using dev->name, but trim it
enough to fit the " N" string to guaranty that you have enough space in this
limited 32 char string and use that instead ? This should fit the uniqueness
requirement without the sacrifice of the only possibly useful information we had
in that limited string.
regards,
Nicolas
>
> This is even resilent to multi chain devices.
>
> Fixes v4l2-compliance:
> Media Controller ioctls:
> fail: v4l2-test-media.cpp(205): v2_entity_names_set.find(key) != v2_entity_names_set.end()
> test MEDIA_IOC_G_TOPOLOGY: FAIL
> fail: v4l2-test-media.cpp(394): num_data_links != num_links
> test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
>
> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org>
> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
> Reviewed-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
> ---
> drivers/media/usb/uvc/uvc_driver.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index 14b60792ffab..037bf80d1100 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2194,6 +2194,7 @@ int uvc_register_video_device(struct uvc_device *dev,
> const struct v4l2_file_operations *fops,
> const struct v4l2_ioctl_ops *ioctl_ops)
> {
> + const char *name;
> int ret;
>
> /* Initialize the video buffers queue. */
> @@ -2222,16 +2223,20 @@ int uvc_register_video_device(struct uvc_device *dev,
> case V4L2_BUF_TYPE_VIDEO_CAPTURE:
> default:
> vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
> + name = "Video Capture";
> break;
> case V4L2_BUF_TYPE_VIDEO_OUTPUT:
> vdev->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
> + name = "Video Output";
> break;
> case V4L2_BUF_TYPE_META_CAPTURE:
> vdev->device_caps = V4L2_CAP_META_CAPTURE | V4L2_CAP_STREAMING;
> + name = "Metadata";
> break;
> }
>
> - strscpy(vdev->name, dev->name, sizeof(vdev->name));
> + snprintf(vdev->name, sizeof(vdev->name), "%s %u", name,
> + stream->header.bTerminalLink);
>
> /*
> * Set the driver data before calling video_register_device, otherwise
As report by Wenqing Liu in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215231
- Overview
kernel NULL pointer dereference triggered in folio_mark_dirty() when mount and operate on a crafted f2fs image
- Reproduce
tested on kernel 5.16-rc3, 5.15.X under root
1. mkdir mnt
2. mount -t f2fs tmp1.img mnt
3. touch tmp
4. cp tmp mnt
F2FS-fs (loop0): sanity_check_inode: inode (ino=49) extent info [5942, 4294180864, 4] is incorrect, run fsck to fix
F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=31340049, run fsck to fix.
BUG: kernel NULL pointer dereference, address: 0000000000000000
folio_mark_dirty+0x33/0x50
move_data_page+0x2dd/0x460 [f2fs]
do_garbage_collect+0xc18/0x16a0 [f2fs]
f2fs_gc+0x1d3/0xd90 [f2fs]
f2fs_balance_fs+0x13a/0x570 [f2fs]
f2fs_create+0x285/0x840 [f2fs]
path_openat+0xe6d/0x1040
do_filp_open+0xc5/0x140
do_sys_openat2+0x23a/0x310
do_sys_open+0x57/0x80
The root cause is for special file: e.g. character, block, fifo or socket file,
f2fs doesn't assign address space operations pointer array for mapping->a_ops field,
so, in a fuzzed image, SSA table indicates a data block belong to special file, when
f2fs tries to migrate that block, it causes NULL pointer access once move_data_page()
calls a_ops->set_dirty_page().
Cc: stable(a)vger.kernel.org
Reported-by: Wenqing Liu <wenqingliu0120(a)gmail.com>
Signed-off-by: Chao Yu <chao(a)kernel.org>
---
fs/f2fs/gc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index a946ce0ead34..e0bdc4361a9b 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1457,7 +1457,8 @@ static int gc_data_segment(struct f2fs_sb_info *sbi, struct f2fs_summary *sum,
if (phase == 3) {
inode = f2fs_iget(sb, dni.ino);
- if (IS_ERR(inode) || is_bad_inode(inode))
+ if (IS_ERR(inode) || is_bad_inode(inode) ||
+ special_file(inode->i_mode))
continue;
if (!down_write_trylock(
--
2.32.0
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5961060692f8b17cd2080620a3d27b95d2ae05ca Mon Sep 17 00:00:00 2001
From: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com>
Date: Mon, 29 Nov 2021 17:32:12 +0800
Subject: [PATCH] net/tls: Fix authentication failure in CCM mode
When the TLS cipher suite uses CCM mode, including AES CCM and
SM4 CCM, the first byte of the B0 block is flags, and the real
IV starts from the second byte. The XOR operation of the IV and
rec_seq should be skip this byte, that is, add the iv_offset.
Fixes: f295b3ae9f59 ("net/tls: Add support of AES128-CCM based ciphers")
Signed-off-by: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com>
Cc: Vakul Garg <vakul.garg(a)nxp.com>
Cc: stable(a)vger.kernel.org # v5.2+
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d3e7ff90889e..dfe623a4e72f 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -521,7 +521,7 @@ static int tls_do_encryption(struct sock *sk,
memcpy(&rec->iv_data[iv_offset], tls_ctx->tx.iv,
prot->iv_size + prot->salt_size);
- xor_iv_with_seq(prot, rec->iv_data, tls_ctx->tx.rec_seq);
+ xor_iv_with_seq(prot, rec->iv_data + iv_offset, tls_ctx->tx.rec_seq);
sge->offset += prot->prepend_size;
sge->length -= prot->prepend_size;
@@ -1499,7 +1499,7 @@ static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
else
memcpy(iv + iv_offset, tls_ctx->rx.iv, prot->salt_size);
- xor_iv_with_seq(prot, iv, tls_ctx->rx.rec_seq);
+ xor_iv_with_seq(prot, iv + iv_offset, tls_ctx->rx.rec_seq);
/* Prepare AAD */
tls_make_aad(aad, rxm->full_len - prot->overhead_size +