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

[PATCH v2 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. A local caller on an atomisp V4L2 device
can drive a kernel heap out-of-bounds write with attacker-controlled
length (and, for both, attacker-controlled contents).

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

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 before the first copy.

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

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   | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

-- 
2.53.0

[PATCH v2 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.

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")
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
 drivers/staging/media/atomisp/pci/atomisp_cmd.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index fec369575d88..5046a0ec8bba 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -3323,6 +3323,17 @@ atomisp_v4l2_framebuffer_to_css_frame(const struct v4l2_framebuffer *arg,
 		goto err;
 	}
 
+	/*
+	 * sizeimage is a separate user-controlled v4l2_pix_format field; the
+	 * CSS frame above is sized from width/height/format. Reject a store
+	 * length that exceeds the allocated frame to avoid a heap overflow of
+	 * res->data in hmm_store() below.
+	 */
+	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

[PATCH v2 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, reachable from
ATOMISP_IOC_S_DIS_VECTOR.

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.

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")
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
 .../staging/media/atomisp/pci/atomisp_cmd.c   | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 5046a0ec8bba..9338aa009923 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -2630,6 +2630,20 @@ int atomisp_cp_dvs_6axis_config(struct atomisp_sub_device *asd,
 
 		dvs_6axis_config->exp_id = t_6axis_config.exp_id;
 
+		/*
+		 * The destination coordinate arrays are sized from the stream
+		 * grid by ia_css_dvs2_6axis_config_allocate(); the copy length
+		 * below uses the user-supplied dimensions. Reject user dims that
+		 * exceed the allocation to avoid a heap out-of-bounds write.
+		 */
+		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 +2696,20 @@ int atomisp_cp_dvs_6axis_config(struct atomisp_sub_device *asd,
 
 		dvs_6axis_config->exp_id = source_6axis_config->exp_id;
 
+		/*
+		 * The destination coordinate arrays are sized from the stream
+		 * grid by ia_css_dvs2_6axis_config_allocate(); the copy length
+		 * below uses the user-supplied dimensions. Reject user dims that
+		 * exceed the allocation to avoid a heap out-of-bounds write.
+		 */
+		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 v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths

[Greg Kroah-Hartman]

On Sat, Jun 27, 2026 at 08:39:21AM +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. A local caller on an atomisp V4L2 device
> can drive a kernel heap out-of-bounds write with attacker-controlled
> length (and, for both, attacker-controlled contents).
> 
> Patch 1 (framebuffer-to-CSS, FPN / S_FBUF path) bounds arg->fmt.sizeimage
> to the frame allocated from width/height/format before the copy/store.
> 
> 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 before the first copy.
> 
> Both were found by 0sec's autonomous vulnerability analysis
> (https://0sec.ai) via static analysis; neither is yet runtime-reproduced
> (Intel Baytrail/Cherrytrail ISP hardware required).

Please document this in the assisted-by tag as the documentation
requires.