This patch is just shared for discussion purposes! Do not land.
In a perfect world, after a deprecation process, we will be able to
remove allow_privacy_override and block all privacy related controls.
If there is any usecase out in the field that resists, we shall move it
into a Kconfig.
This patch shows how the transition to Kconfig can look.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
drivers/media/usb/uvc/Kconfig | 11 +++++++++++
drivers/media/usb/uvc/uvc_ctrl.c | 4 ++--
drivers/media/usb/uvc/uvc_driver.c | 20 --------------------
drivers/media/usb/uvc/uvc_v4l2.c | 4 ++--
drivers/media/usb/uvc/uvcvideo.h | 1 -
5 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/media/usb/uvc/Kconfig b/drivers/media/usb/uvc/Kconfig
index 579532272fd6..7c0f2260d135 100644
--- a/drivers/media/usb/uvc/Kconfig
+++ b/drivers/media/usb/uvc/Kconfig
@@ -20,3 +20,14 @@ config USB_VIDEO_CLASS_INPUT_EVDEV
to report button events.
If you are in doubt, say Y.
+
+config USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE
+ bool "Allow overriding the privacy controls"
+ default n
+ depends on USB_VIDEO_CLASS && BROKEN
+ help
+ If this option is enabled, the privacy related controls, such as
+ the ones controlling the privacy LED will be accessible from
+ userspace.
+
+ If you are in doubt, say N.
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 3ca108b83f1d..c9c195974765 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -3075,9 +3075,9 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
}
if (uvc_ctrl_is_privacy_control(entity->guid, xqry->selector) &&
- !uvc_allow_privacy_override_param) {
+ !IS_ENABLED(CONFIG_USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE)) {
dev_warn_once(&chain->dev->intf->dev,
- "Privacy related controls can only be accessed if module parameter allow_privacy_override is true\n");
+ "Privacy related controls can only be accessed if CONFIG_USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE is true\n");
uvc_dbg(chain->dev, CONTROL, "Blocking access to privacy related Control %pUl/%u\n",
entity->guid, xqry->selector);
return -EACCES;
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 74c9dea29d36..b0ca81d924b6 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -36,7 +36,6 @@ unsigned int uvc_no_drop_param = 1;
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;
@@ -2506,25 +2505,6 @@ 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 6d4f027c8402..f83abbd13aca 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -134,9 +134,9 @@ static int uvc_ioctl_xu_ctrl_map(struct uvc_video_chain *chain,
}
if (uvc_ctrl_is_privacy_control(xmap->entity, xmap->selector) &&
- !uvc_allow_privacy_override_param) {
+ !IS_ENABLED(CONFIG_USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE)) {
dev_warn_once(&chain->dev->intf->dev,
- "Privacy related controls can only be mapped if module parameter allow_privacy_override is true\n");
+ "Privacy related controls can only be mapped if CONFIG_USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE is true\n");
return -EACCES;
}
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 362110d58ca3..2898384d5f78 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -664,7 +664,6 @@ extern unsigned int uvc_no_drop_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 { \
--
2.53.0.851.ga537e3e6e9-googOn Mon, Mar 16, 2026 at 01:34:47PM +0000, Ricardo Ribalda wrote: > This patch is just shared for discussion purposes! Do not land. > > In a perfect world, after a deprecation process, we will be able to > remove allow_privacy_override and block all privacy related controls. Why add something you are only going to remove in the future? What has changed to require this now, and will change in the future to make it not needed? > If there is any usecase out in the field that resists, we shall move it > into a Kconfig. What does this mean? How will anyone know to "resist"? > This patch shows how the transition to Kconfig can look. I'm confused as to what you want to do here... greg k-h
Hi Greg On Wed, 18 Mar 2026 at 15:17, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Mon, Mar 16, 2026 at 01:34:47PM +0000, Ricardo Ribalda wrote: > > This patch is just shared for discussion purposes! Do not land. > > > > In a perfect world, after a deprecation process, we will be able to > > remove allow_privacy_override and block all privacy related controls. > > Why add something you are only going to remove in the future? What has > changed to require this now, and will change in the future to make it > not needed? Currently, any application with camera access can manipulate the privacy LED. I believe this is a security flaw; ideally, the kernel should block all such controls by default. However, blocking these controls immediately might be seen as a regression for certain users. I added allow_privacy_override to: - Prevent breaking existing workflows immediately upon a kernel update. - Give users time to report why they still need manual LED control. The goal is to gather these use cases over the next 1–2 years. Once we understand the legitimate needs, we can either implement a proper specialized mechanism for them or move the toggle to a Kconfig option for those who explicitly need to opt-in to the old behavior or simply remove the toggle altogether. For the record, identified use cases so far: - Old hardware with red LEDs that reflect on glasses. (Likely a dying niche). - Using cameras as baby monitors where the LED disturbs sleep. (Arguably solvable with a piece of tape on the LED, but still a reported use case). > > > If there is any usecase out in the field that resists, we shall move it > > into a Kconfig. > > What does this mean? How will anyone know to "resist"? My phrasing was poor, sorry about that. What I mean is: if, after a deprecation period, we find there are still legitimate reasons to allow LED overrides, we will move the functionality behind a Kconfig option (e.g., USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE) or other option. If no one reports a need for it, we simply remove the override capability entirely. > > > This patch shows how the transition to Kconfig can look. > > I'm confused as to what you want to do here... This patch is just a RFC to demonstrate the final state if we decide a Kconfig option is necessary. The actual plan is to land patches 1-3 first, wait for feedback, and only then decide if we need the Kconfig transition or a full removal or something else. > > greg k-h -- Ricardo Ribalda
Hi Ricardo, On Wed, 2026-03-18 at 15:57 +0100, Ricardo Ribalda wrote: > Hi Greg > > On Wed, 18 Mar 2026 at 15:17, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Mar 16, 2026 at 01:34:47PM +0000, Ricardo Ribalda wrote: > > > This patch is just shared for discussion purposes! Do not land. > > > > > > In a perfect world, after a deprecation process, we will be able to > > > remove allow_privacy_override and block all privacy related controls. > > > > Why add something you are only going to remove in the future? What has > > changed to require this now, and will change in the future to make it > > not needed? > > Currently, any application with camera access can manipulate the > privacy LED. I believe this is a security flaw; ideally, the kernel > should block all such controls by default. > > However, blocking these controls immediately might be seen as a > regression for certain users. I added allow_privacy_override to: > - Prevent breaking existing workflows immediately upon a kernel update. > - Give users time to report why they still need manual LED control. > > The goal is to gather these use cases over the next 1–2 years. Once we > understand the legitimate needs, we can either implement a proper > specialized mechanism for them or move the toggle to a Kconfig option > for those who explicitly need to opt-in to the old behavior or simply > remove the toggle altogether. > > For the record, identified use cases so far: > - Old hardware with red LEDs that reflect on glasses. (Likely a dying niche). Older Logitech cameras, like the c920, have fairly large LEDs that can be reflective, and it's hard to cover them up aesthetically. Laurent wrote [1] that's why Logitech added this functionality a long time ago. You can find old Logitech software for Windows that still allows you to turn off the LEDs [2]. I tried it in a Win10 VM and it really works. The c920 is a very popular camera, still available in stores today. Amazon says it sells 12k of them per month [3]. 1: https://lore.kernel.org/all/20251119041907.GH10711@pendragon.ideasonboard.com/ 2: https://www.reddit.com/r/logitech/comments/v641x6/comment/nr22zo7/ 3: https://www.amazon.com/s?k=logitech+c920 > - Using cameras as baby monitors where the LED disturbs sleep. And pet cameras and surveillance cameras don't need LEDs either. > (Arguably solvable with a piece of tape on the LED, but still a > reported use case). > Furthermore, if we filter these two Logitech XUs, we could then add the similar XUs of the camera modules in laptops and this could be an ever- growing list. > Best regards, Gergo Koteles
Hi Gergo On Thu, 19 Mar 2026 at 12:50, Gergo Koteles <soyer@irl.hu> wrote: > > Hi Ricardo, > > On Wed, 2026-03-18 at 15:57 +0100, Ricardo Ribalda wrote: > > Hi Greg > > > > On Wed, 18 Mar 2026 at 15:17, Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > > > > On Mon, Mar 16, 2026 at 01:34:47PM +0000, Ricardo Ribalda wrote: > > > > This patch is just shared for discussion purposes! Do not land. > > > > > > > > In a perfect world, after a deprecation process, we will be able to > > > > remove allow_privacy_override and block all privacy related controls. > > > > > > Why add something you are only going to remove in the future? What has > > > changed to require this now, and will change in the future to make it > > > not needed? > > > > Currently, any application with camera access can manipulate the > > privacy LED. I believe this is a security flaw; ideally, the kernel > > should block all such controls by default. > > > > However, blocking these controls immediately might be seen as a > > regression for certain users. I added allow_privacy_override to: > > - Prevent breaking existing workflows immediately upon a kernel update. > > - Give users time to report why they still need manual LED control. > > > > The goal is to gather these use cases over the next 1–2 years. Once we > > understand the legitimate needs, we can either implement a proper > > specialized mechanism for them or move the toggle to a Kconfig option > > for those who explicitly need to opt-in to the old behavior or simply > > remove the toggle altogether. > > > > For the record, identified use cases so far: > > - Old hardware with red LEDs that reflect on glasses. (Likely a dying niche). > > Older Logitech cameras, like the c920, have fairly large LEDs that can > be reflective, and it's hard to cover them up aesthetically. Laurent > wrote [1] that's why Logitech added this functionality a long time ago. > > You can find old Logitech software for Windows that still allows you to > turn off the LEDs [2]. I tried it in a Win10 VM and it really works. In the same link you will find that Logitech has removed that option in newer version of the Logitech software and a "Official Logitech Representative" says that: ```Please be informed that there is no way to disable the blue led light on the webcam as that is the indicator that the webcam is active and its mainly for security purpose.``` Other users say that ```I would not buy a webcam with an led that can be switched off and that can watch me without any chance noticing it.``` This is definitely a requested feature by the users and it seems even the vendor has realized that the security risk of a "stealth" camera outweighs the benefit of turning off the LED. > > The c920 is a very popular camera, still available in stores today. > Amazon says it sells 12k of them per month [3]. > > 1: > https://lore.kernel.org/all/20251119041907.GH10711@pendragon.ideasonboard.com/ > > 2: https://www.reddit.com/r/logitech/comments/v641x6/comment/nr22zo7/ > > 3: https://www.amazon.com/s?k=logitech+c920 > > > - Using cameras as baby monitors where the LED disturbs sleep. > > And pet cameras and surveillance cameras don't need LEDs either. Agree. All surveillance cameras. All those special cases can use the allow_privacy_override parameter until we find a good way to handle their use case. > > > (Arguably solvable with a piece of tape on the LED, but still a > > reported use case). > > > > Furthermore, if we filter these two Logitech XUs, we could then add the > similar XUs of the camera modules in laptops and this could be an ever- > growing list. That is the goal, to have a list as comprehensive as possible. > > > > Best regards, > Gergo Koteles -- Ricardo Ribalda
© 2016 - 2026 Red Hat, Inc.