drivers/staging/media/atomisp/pci/atomisp_ioctl.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
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
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
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
© 2016 - 2025 Red Hat, Inc.