linux-kernel - Re: [PATCH v2 2/4] media: uvcvideo: Do not set an async control owned by other fh

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241128223343.GH25731@pendragon.ideasonboard.com>
Date: Fri, 29 Nov 2024 00:33:43 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Hans de Goede <hdegoede@...hat.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Guennadi Liakhovetski <guennadi.liakhovetski@...el.com>,
	Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Hans Verkuil <hverkuil-cisco@...all.nl>
Subject: Re: [PATCH v2 2/4] media: uvcvideo: Do not set an async control
 owned by other fh

On Thu, Nov 28, 2024 at 11:28:29PM +0100, Ricardo Ribalda wrote:
> On Thu, 28 Nov 2024 at 23:22, Laurent Pinchart wrote:
> >
> > Hi Ricardo,
> >
> > (CC'ing Hans Verkuil)
> >
> > Thank you for the patch.
> >
> > On Wed, Nov 27, 2024 at 12:14:50PM +0000, Ricardo Ribalda wrote:
> > > If a file handle is waiting for a response from an async control, avoid
> > > that other file handle operate with it.
> > >
> > > Without this patch, the first file handle will never get the event
> > > associated with that operation, which can lead to endless loops in
> > > applications. Eg:
> > > If an application A wants to change the zoom and to know when the
> > > operation has completed:
> > > it will open the video node, subscribe to the zoom event, change the
> > > control and wait for zoom to finish.
> > > If before the zoom operation finishes, another application B changes
> > > the zoom, the first app A will loop forever.
> >
> > Hans, the V4L2 specification isn't very clear on this. I see pros and
> > cons for both behaviours, with a preference for the current behaviour,
> > as with this patch the control will remain busy until the file handle is
> > closed if the device doesn't send the control event for any reason. What
> > do you think ?
> 
> Just one small clarification. The same file handler can change the
> value of the async control as many times as it wants, even if the
> operation has not finished.
> 
> It will be other file handles that will get -EBUSY if they try to use
> an async control with an unfinished operation started by another fh.

Yes, I should have been more precised. If the device doesn't send the
control event, then all other file handles will be prevented from
setting the control until the file handle that set it first gets closed.

> > > Cc: stable@...r.kernel.org
> > > Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control Change interrupt arrives")
> > > Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> > > ---
> > >  drivers/media/usb/uvc/uvc_ctrl.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> > > index b6af4ff92cbd..3f8ae35cb3bc 100644
> > > --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > > +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> > > @@ -1955,6 +1955,10 @@ int uvc_ctrl_set(struct uvc_fh *handle,
> > >       if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
> > >               return -EACCES;
> > >
> > > +     /* Other file handle is waiting a response from this async control. */
> > > +     if (ctrl->handle && ctrl->handle != handle)
> > > +             return -EBUSY;
> > > +
> > >       /* Clamp out of range values. */
> > >       switch (mapping->v4l2_type) {
> > >       case V4L2_CTRL_TYPE_INTEGER:

-- 
Regards,

Laurent Pinchart