[PATCH] staging: media: atomisp: add missing mutex lock in atomisp_s_fmt_cap

[PATCH] staging: media: atomisp: add missing mutex lock in atomisp_s_fmt_cap

[Abdelrahman Fekry]

The function atomisp_set_fmt() modifies shared device state and expects
callers to hold the isp->mutex for synchronization. While most internal
callers correctly lock the mutex before invoking atomisp_set_fmt(), the
V4L2 ioctl handler atomisp_s_fmt_cap() does not.

This results in an unsafe execution path for VIDIOC_S_FMT ioctls
(e.g. via v4l2-ctl), where shared structures such as pipe->pix and
pipe->frame_info may be modified concurrently without proper protection.

- Fix this by explicitly locking isp->mutex in atomisp_s_fmt_cap().

Signed-off-by: Abdelrahman Fekry <abdelrahmanfekry375@gmail.com>
---
 drivers/staging/media/atomisp/pci/atomisp_ioctl.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_ioctl.c b/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
index bb8b2f2213b0..9bf0be00657c 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_ioctl.c
@@ -416,8 +416,15 @@ static int atomisp_s_fmt_cap(struct file *file, void *fh,
 			     struct v4l2_format *f)
 {
 	struct video_device *vdev = video_devdata(file);
+	struct atomisp_device *isp = video_get_drvdata(vdev);
+
+	int ret;
 
-	return atomisp_set_fmt(vdev, f);
+	mutex_lock(&isp->mutex);
+	ret = atomisp_set_fmt(vdev, f);
+	mutex_unlock(&isp->mutex);
+
+	return ret;
 }
 
 /*
-- 
2.25.1

Re: [PATCH] staging: media: atomisp: add missing mutex lock in atomisp_s_fmt_cap

[Andy Shevchenko]

On Wed, Jul 16, 2025 at 4:42 AM Abdelrahman Fekry
<abdelrahmanfekry375@gmail.com> wrote:
>
> The function atomisp_set_fmt() modifies shared device state and expects
> callers to hold the isp->mutex for synchronization. While most internal
> callers correctly lock the mutex before invoking atomisp_set_fmt(), the
> V4L2 ioctl handler atomisp_s_fmt_cap() does not.
>
> This results in an unsafe execution path for VIDIOC_S_FMT ioctls
> (e.g. via v4l2-ctl), where shared structures such as pipe->pix and
> pipe->frame_info may be modified concurrently without proper protection.
>
> - Fix this by explicitly locking isp->mutex in atomisp_s_fmt_cap().

If it's a fix, please add the Fixes tag.

...

> -       return atomisp_set_fmt(vdev, f);
> +       mutex_lock(&isp->mutex);
> +       ret = atomisp_set_fmt(vdev, f);
> +       mutex_unlock(&isp->mutex);

Side note: Can you consider switching the driver to use cleanup.h
(guard()(), scoped_guard(), __free(), etc)?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] staging: media: atomisp: add missing mutex lock in atomisp_s_fmt_cap

[Abdelrahman Fekry]

Hi Andy,

On Wed, Jul 16, 2025 at 11:11 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Jul 16, 2025 at 4:42 AM Abdelrahman Fekry
> <abdelrahmanfekry375@gmail.com> wrote:
> >
> > The function atomisp_set_fmt() modifies shared device state and expects
> > callers to hold the isp->mutex for synchronization. While most internal
> > callers correctly lock the mutex before invoking atomisp_set_fmt(), the
> > V4L2 ioctl handler atomisp_s_fmt_cap() does not.
> >
> > This results in an unsafe execution path for VIDIOC_S_FMT ioctls
> > (e.g. via v4l2-ctl), where shared structures such as pipe->pix and
> > pipe->frame_info may be modified concurrently without proper protection.
> >
> > - Fix this by explicitly locking isp->mutex in atomisp_s_fmt_cap().
>
> If it's a fix, please add the Fixes tag.
>
will do , thanks.
> ...
>
> > -       return atomisp_set_fmt(vdev, f);
> > +       mutex_lock(&isp->mutex);
> > +       ret = atomisp_set_fmt(vdev, f);
> > +       mutex_unlock(&isp->mutex);
>
> Side note: Can you consider switching the driver to use cleanup.h
> (guard()(), scoped_guard(), __free(), etc)?
will look at it .

Would you please look at this patch series [1] , it hasn't got any feedback
and i have more work that builds on it.

> --
> With Best Regards,
> Andy Shevchenko

Link: https://lore.kernel.org/all/20250712191325.132666-1-abdelrahmanfekry375@gmail.com/
[1]
Best Regards,
Abdelrahman Fekry