[PATCH v3 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths

[PATCH v3 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths

[Doruk Tan Ozturk]

Two ioctl paths in the Intel AtomISP staging driver share the same
defect class: one user-controlled field sizes the destination buffer
while a separate user-controlled field sizes the copy/store, with no
cross-validation between them, so the store can overflow the allocation
with attacker-controlled length (and contents).

Patch 1 (framebuffer-to-CSS, FPN / S_ISP_FPN_TABLE path) bounds
arg->fmt.sizeimage to the frame allocated from width/height/format.

Patch 2 (S_DIS_VECTOR DVS 6-axis config) bounds the user-supplied
width/height dimensions to the stream-grid-sized destination config in
both the ISP2401 and ISP2400 branches.

Reachability caveat: both paths are private ioctls, and private ioctls
are currently disabled by 2b7eb2c5dc72 ("staging: media: atomisp:
Disallow all private IOCTLs") -- atomisp_vidioc_default() returns
-EINVAL for any non-zero cmd before the dispatch switch -- so neither is
reachable from userspace today. These are hardening of the
disabled-but-revivable private-ioctl paths rather than a live overflow.

Both were found by 0sec's autonomous vulnerability analysis
(https://0sec.ai) via static analysis; neither is runtime-reproduced
(Intel Baytrail/Cherrytrail ISP hardware required).

v3:
 - add Assisted-by: tag (Greg KH)
 - drop the explanatory comments; the rationale is in the commit
   messages (Dan Carpenter)
 - note the private-ioctl gate in each commit message and here
v2:
 - add Fixes: tags (Dan Carpenter)

Doruk Tan Ozturk (2):
  media: atomisp: validate sizeimage against the allocated frame in
    framebuffer-to-CSS
  media: atomisp: bound DVS 6-axis table dimensions to the allocated
    config

 .../staging/media/atomisp/pci/atomisp_cmd.c   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

-- 
2.53.0

[PATCH v3 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS

[Doruk Tan Ozturk]

atomisp_v4l2_framebuffer_to_css_frame() allocates the CSS frame from
arg->fmt.{width,height,pixelformat}, but then copies and stores
arg->fmt.sizeimage bytes into it. sizeimage is an independent,
user-controlled v4l2_pix_format field, and nothing checks it against the
allocated frame, so a sizeimage larger than width*height*bpp overflows
res->data in hmm_store().

Reject a sizeimage that exceeds the allocated frame (res->data_bytes)
before the copy/store.

Note this ioctl path (S_ISP_FPN_TABLE) is currently gated off by
2b7eb2c5dc72 ("staging: media: atomisp: Disallow all private IOCTLs"),
so it is not reachable from userspace today; this hardens the
disabled-but-revivable path.

Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Found by static analysis; not yet runtime-reproduced (Intel
Baytrail/Cherrytrail ISP hardware required).

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Assisted-by: 0sec:claude-opus-4.8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index fec369575d88..04e7b2e03f34 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -3323,6 +3323,11 @@ atomisp_v4l2_framebuffer_to_css_frame(const struct v4l2_framebuffer *arg,
 		goto err;
 	}
 
+	if (arg->fmt.sizeimage > res->data_bytes) {
+		ret = -EINVAL;
+		goto err;
+	}
+
 	tmp_buf = vmalloc(arg->fmt.sizeimage);
 	if (!tmp_buf) {
 		ret = -ENOMEM;
-- 
2.53.0

Re: [PATCH v3 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS

[Andy Shevchenko]

On Sat, Jun 27, 2026 at 12:01:18PM +0200, Doruk Tan Ozturk wrote:
> atomisp_v4l2_framebuffer_to_css_frame() allocates the CSS frame from
> arg->fmt.{width,height,pixelformat}, but then copies and stores
> arg->fmt.sizeimage bytes into it. sizeimage is an independent,
> user-controlled v4l2_pix_format field, and nothing checks it against the
> allocated frame, so a sizeimage larger than width*height*bpp overflows
> res->data in hmm_store().
> 
> Reject a sizeimage that exceeds the allocated frame (res->data_bytes)
> before the copy/store.
> 
> Note this ioctl path (S_ISP_FPN_TABLE) is currently gated off by
> 2b7eb2c5dc72 ("staging: media: atomisp: Disallow all private IOCTLs"),
> so it is not reachable from userspace today; this hardens the
> disabled-but-revivable path.

> Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
> Found by static analysis; not yet runtime-reproduced (Intel
> Baytrail/Cherrytrail ISP hardware required).

This can go to the comment block. Otherwise you have a tag below already.
Same for other patches in the series.

> Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
> Assisted-by: 0sec:claude-opus-4.8
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3 2/2] media: atomisp: bound DVS 6-axis table dimensions to the allocated config

[Doruk Tan Ozturk]

atomisp_cp_dvs_6axis_config() allocates the DVS 6-axis coordinate arrays
from the stream grid via ia_css_dvs2_6axis_config_allocate(), but then
uses the user-supplied width_y/height_y/width_uv/height_uv as the
copy_from_compatible() length. The reallocate-on-mismatch path also
re-allocates from the stream grid, so the destination is always
stream-sized while the copy length is user-sized. User dimensions larger
than the allocated grid produce a heap out-of-bounds write with
attacker-controlled length and contents.

Reject user dimensions that exceed the allocated config in both the
ISP2401 (t_6axis_config) and ISP2400/else (source_6axis_config) branches
before the first copy.

Note this ioctl path (S_DIS_VECTOR) is currently gated off by
2b7eb2c5dc72 ("staging: media: atomisp: Disallow all private IOCTLs"),
so it is not reachable from userspace today; this hardens the
disabled-but-revivable path.

Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Found by static analysis; not yet runtime-reproduced (Intel
Baytrail/Cherrytrail ISP hardware required).

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Assisted-by: 0sec:claude-opus-4.8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 04e7b2e03f34..ea543025fd9c 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -2630,6 +2630,14 @@ int atomisp_cp_dvs_6axis_config(struct atomisp_sub_device *asd,
 
 		dvs_6axis_config->exp_id = t_6axis_config.exp_id;
 
+		if (t_6axis_config.width_y > dvs_6axis_config->width_y ||
+		    t_6axis_config.height_y > dvs_6axis_config->height_y ||
+		    t_6axis_config.width_uv > dvs_6axis_config->width_uv ||
+		    t_6axis_config.height_uv > dvs_6axis_config->height_uv) {
+			ret = -EINVAL;
+			goto error;
+		}
+
 		if (copy_from_compatible(dvs_6axis_config->xcoords_y,
 					t_6axis_config.xcoords_y,
 					t_6axis_config.width_y *
@@ -2682,6 +2690,14 @@ int atomisp_cp_dvs_6axis_config(struct atomisp_sub_device *asd,
 
 		dvs_6axis_config->exp_id = source_6axis_config->exp_id;
 
+		if (source_6axis_config->width_y > dvs_6axis_config->width_y ||
+		    source_6axis_config->height_y > dvs_6axis_config->height_y ||
+		    source_6axis_config->width_uv > dvs_6axis_config->width_uv ||
+		    source_6axis_config->height_uv > dvs_6axis_config->height_uv) {
+			ret = -EINVAL;
+			goto error;
+		}
+
 		if (copy_from_compatible(dvs_6axis_config->xcoords_y,
 					source_6axis_config->xcoords_y,
 					source_6axis_config->width_y *
-- 
2.53.0

Re: [PATCH v3 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths

[Andy Shevchenko]

On Sat, Jun 27, 2026 at 12:01:17PM +0200, Doruk Tan Ozturk wrote:
> Two ioctl paths in the Intel AtomISP staging driver share the same
> defect class: one user-controlled field sizes the destination buffer
> while a separate user-controlled field sizes the copy/store, with no
> cross-validation between them, so the store can overflow the allocation
> with attacker-controlled length (and contents).
> 
> Patch 1 (framebuffer-to-CSS, FPN / S_ISP_FPN_TABLE path) bounds
> arg->fmt.sizeimage to the frame allocated from width/height/format.
> 
> Patch 2 (S_DIS_VECTOR DVS 6-axis config) bounds the user-supplied
> width/height dimensions to the stream-grid-sized destination config in
> both the ISP2401 and ISP2400 branches.

> Reachability caveat: both paths are private ioctls, and private ioctls
> are currently disabled by 2b7eb2c5dc72 ("staging: media: atomisp:
> Disallow all private IOCTLs") -- atomisp_vidioc_default() returns
> -EINVAL for any non-zero cmd before the dispatch switch -- so neither is
> reachable from userspace today. These are hardening of the
> disabled-but-revivable private-ioctl paths rather than a live overflow.

This makes these patches low priority. Why do we need to spend time on them
at all? Nobody knows right now how the revival of the mentioned private IOCTLs
will look like. I'm pretty sure it will be some generic ones that this code
should morph to. Since it looks like your tool is useful, can you check the
rest and reachable parts of the driver first?

> Both were found by 0sec's autonomous vulnerability analysis
> (https://0sec.ai) via static analysis; neither is runtime-reproduced
> (Intel Baytrail/Cherrytrail ISP hardware required).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths

[Doruk (0sec)]

On Mon, Jun 29, 2026 at 06:28:44PM +0200, Andy Shevchenko wrote:
> This makes these patches low priority. Why do we need to spend time on
> them at all? Nobody knows right now how the revival of the mentioned
> private IOCTLs will look like. I'm pretty sure it will be some generic
> ones that this code should morph to. Since it looks like your tool is
> useful, can you check the rest and reachable parts of the driver first?

Fair point, I'll drop this series and point it to the
reachable parts of the driver (and the wider media stack) instead.

Appreciate the review.
Doruk




On Mon, 29 Jun 2026 at 18:28, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Sat, Jun 27, 2026 at 12:01:17PM +0200, Doruk Tan Ozturk wrote:
> > Two ioctl paths in the Intel AtomISP staging driver share the same
> > defect class: one user-controlled field sizes the destination buffer
> > while a separate user-controlled field sizes the copy/store, with no
> > cross-validation between them, so the store can overflow the allocation
> > with attacker-controlled length (and contents).
> >
> > Patch 1 (framebuffer-to-CSS, FPN / S_ISP_FPN_TABLE path) bounds
> > arg->fmt.sizeimage to the frame allocated from width/height/format.
> >
> > Patch 2 (S_DIS_VECTOR DVS 6-axis config) bounds the user-supplied
> > width/height dimensions to the stream-grid-sized destination config in
> > both the ISP2401 and ISP2400 branches.
>
> > Reachability caveat: both paths are private ioctls, and private ioctls
> > are currently disabled by 2b7eb2c5dc72 ("staging: media: atomisp:
> > Disallow all private IOCTLs") -- atomisp_vidioc_default() returns
> > -EINVAL for any non-zero cmd before the dispatch switch -- so neither is
> > reachable from userspace today. These are hardening of the
> > disabled-but-revivable private-ioctl paths rather than a live overflow.
>
> This makes these patches low priority. Why do we need to spend time on them
> at all? Nobody knows right now how the revival of the mentioned private IOCTLs
> will look like. I'm pretty sure it will be some generic ones that this code
> should morph to. Since it looks like your tool is useful, can you check the
> rest and reachable parts of the driver first?
>
> > Both were found by 0sec's autonomous vulnerability analysis
> > (https://0sec.ai) via static analysis; neither is runtime-reproduced
> > (Intel Baytrail/Cherrytrail ISP hardware required).
>
> --
> With Best Regards,
> Andy Shevchenko
>
>