| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <448fb5ce-f369-4796-b29b-ae03c1314b3a@kernel.org>
Date: Mon, 8 Dec 2025 12:58:46 +0100
From: Hans de Goede <hansg@...nel.org>
To: Ricardo Ribalda <ribalda@...omium.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 5/6] media: uvcvideo: Introduce allow_privacy_override
param
Hi,
On 19-Nov-25 8:37 PM, Ricardo Ribalda wrote:
> Some camera modules have XU controls that can configure the behaviour of
> the privacy LED.
>
> Block mapping of those controls, unless the module is configured with
> a new parameter: allow_privacy_override.
>
> This is just an interim solution. Based on the users feedback, we will
> either put the privacy controls behind a CONFIG option, or completely
> block them.
>
> Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 38 ++++++++++++++++++++++++++++++++++++++
> drivers/media/usb/uvc/uvc_driver.c | 20 ++++++++++++++++++++
> drivers/media/usb/uvc/uvc_v4l2.c | 7 +++++++
> drivers/media/usb/uvc/uvcvideo.h | 2 ++
> include/linux/usb/uvc.h | 4 ++++
> 5 files changed, 71 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> index 57ce486f22bbc404a1f127539eb2d12373431631..d9cbb942f798dc7138608982a5d3e3ef9f8141f6 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -2951,6 +2951,35 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device *dev,
> return ret;
> }
>
> +bool uvc_ctrl_is_privacy_control(u8 entity[16], u8 selector)
> +{
> + /*
> + * This list is not exhaustive, it is a best effort to block access to
> + * non documented controls that can affect user's privacy.
> + */
> + struct privacy_control {
> + u8 entity[16];
> + u8 selector;
> + } privacy_control[] = {
> + {
> + .entity = UVC_GUID_LOGITECH_USER_HW_CONTROL_V1,
> + .selector = 1,
> + },
> + {
> + .entity = UVC_GUID_LOGITECH_PERIPHERAL,
> + .selector = 9,
> + },
> + };
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(privacy_control); i++)
> + if (!memcmp(entity, privacy_control[i].entity, 16) &&
> + selector == privacy_control[i].selector)
> + return true;
> +
> + return false;
> +}
> +
> int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> struct uvc_xu_control_query *xqry)
> {
> @@ -2995,6 +3024,15 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> return -ENOENT;
> }
>
> + if (uvc_ctrl_is_privacy_control(entity->guid, xqry->selector) &&
> + !uvc_allow_privacy_override_param) {
> + dev_warn_once(&chain->dev->intf->dev,
> + "Privacy related controls can only be accessed if param allow_privacy_override is true\n");
I would do /s/param/module parameter/ in the message here. I know it makes the message a bit
long but I'm not sure all users will understand what kind of parameter is intended otherwise.
> + uvc_dbg(chain->dev, CONTROL, "Blocking access to privacy related Control %pUl/%u\n",
> + entity->guid, xqry->selector);
> + return -EACCES;
> + }
> +
> if (mutex_lock_interruptible(&chain->ctrl_mutex))
> return -ERESTARTSYS;
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index 71563d8f4bcf581694ccd4b665ff52b629caa0b6..c292bf8b6f57e9fdacee726285f5b46e638fd317 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -35,6 +35,7 @@ unsigned int uvc_hw_timestamps_param;
> static unsigned int uvc_quirks_param = -1;
> unsigned int uvc_dbg_param;
> unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
> +bool uvc_allow_privacy_override_param;
>
> static struct usb_driver uvc_driver;
>
> @@ -2474,6 +2475,25 @@ MODULE_PARM_DESC(trace, "Trace level bitmask");
> module_param_named(timeout, uvc_timeout_param, uint, 0644);
> MODULE_PARM_DESC(timeout, "Streaming control requests timeout");
>
> +static int param_set_privacy(const char *val, const struct kernel_param *kp)
> +{
> + pr_warn_once("uvcvideo: " DEPRECATED
> + "allow_privacy_override parameter will be eventually removed.\n");
> + return param_set_bool(val, kp);
> +}
> +
> +static const struct kernel_param_ops param_ops_privacy = {
> + .set = param_set_privacy,
> + .get = param_get_bool,
> +};
> +
> +param_check_bool(allow_privacy_override, &uvc_allow_privacy_override_param);
> +module_param_cb(allow_privacy_override, ¶m_ops_privacy,
> + &uvc_allow_privacy_override_param, 0644);
> +__MODULE_PARM_TYPE(allow_privacy_override, "bool");
> +MODULE_PARM_DESC(allow_privacy_override,
> + "Allow access to privacy related controls");
> +
> /* ------------------------------------------------------------------------
> * Driver initialization and cleanup
> */
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> index 03c64b5698bf4331fed8437fa6e9c726a07450bd..510cf47c86a62ba7fe3c7fa51be82c996cf37f9f 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -133,6 +133,13 @@ static int uvc_ioctl_xu_ctrl_map(struct uvc_video_chain *chain,
> return -EINVAL;
> }
>
> + if (uvc_ctrl_is_privacy_control(xmap->entity, xmap->selector) &&
> + !uvc_allow_privacy_override_param) {
> + dev_warn_once(&chain->dev->intf->dev,
> + "Privacy related controls can only be mapped if param allow_privacy_override is true\n");
Same comment on the msg.
> + return -EACCES;
Did you test this with uvcdynctrl? will it log the error and continue with other controls,
or will it abort mapping controls when it hits this ?
I agree with the change and with the -EACCES error return I'm just wondering how
known userspace consumers of the API will react to this change.
I've been thinking a bit about this and although not ideal I agree that this approach
is likely the best way to deal with the Logitech custom privacy LED controls.
Regards,
Hans
> + }
> +
> map = kzalloc(sizeof(*map), GFP_KERNEL);
> if (map == NULL)
> return -ENOMEM;
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 9a86d7f1f6ea022dace87614030bf0fde0d260f0..4b1a70e3100bbf2180411a865a89952a81d0f0a4 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -662,6 +662,7 @@ extern unsigned int uvc_clock_param;
> extern unsigned int uvc_dbg_param;
> extern unsigned int uvc_timeout_param;
> extern unsigned int uvc_hw_timestamps_param;
> +extern bool uvc_allow_privacy_override_param;
>
> #define uvc_dbg(_dev, flag, fmt, ...) \
> do { \
> @@ -792,6 +793,7 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> struct uvc_xu_control_query *xqry);
>
> void uvc_ctrl_cleanup_fh(struct uvc_fh *handle);
> +bool uvc_ctrl_is_privacy_control(u8 entity[16], u8 selector);
>
> /* Utility functions */
> struct usb_host_endpoint *uvc_find_endpoint(struct usb_host_interface *alts,
> diff --git a/include/linux/usb/uvc.h b/include/linux/usb/uvc.h
> index dea23aabbad48270c807463c1a7e1c0d1b79fc1f..70c2a7d2523611418aba363328f76667d379b571 100644
> --- a/include/linux/usb/uvc.h
> +++ b/include/linux/usb/uvc.h
> @@ -49,6 +49,10 @@
> #define UVC_GUID_LOGITECH_PERIPHERAL \
> {0x21, 0x2d, 0xe5, 0xff, 0x30, 0x80, 0x2c, 0x4e, \
> 0x82, 0xd9, 0xf5, 0x87, 0xd0, 0x05, 0x40, 0xbd }
> +#define UVC_GUID_LOGITECH_USER_HW_CONTROL_V1 \
> + {0x82, 0x06, 0x61, 0x63, 0x70, 0x50, 0xab, 0x49, \
> + 0xb8, 0xcc, 0xb3, 0x85, 0x5e, 0x8d, 0x22, 0x1f }
> +
>
> /* https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5#222-extension-unit-controls */
> #define UVC_MSXU_CONTROL_FOCUS 0x01
>
Powered by blists - more mailing lists