Linux Media Controller development
 help / color / mirror / Atom feed
* [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths
@ 2026-06-27  6:39 Doruk Tan Ozturk
  2026-06-27  6:39 ` [PATCH v2 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS Doruk Tan Ozturk
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Doruk Tan Ozturk @ 2026-06-27  6:39 UTC (permalink / raw)
  To: Hans de Goede, Andy Shevchenko, Mauro Carvalho Chehab,
	Greg Kroah-Hartman
  Cc: Dan Carpenter, Sakari Ailus, linux-media, linux-staging,
	linux-kernel, 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v2 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS
  2026-06-27  6:39 [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Doruk Tan Ozturk
@ 2026-06-27  6:39 ` Doruk Tan Ozturk
  2026-06-27  6:39 ` [PATCH v2 2/2] media: atomisp: bound DVS 6-axis table dimensions to the allocated config Doruk Tan Ozturk
  2026-06-27  7:57 ` [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Greg Kroah-Hartman
  2 siblings, 0 replies; 5+ messages in thread
From: Doruk Tan Ozturk @ 2026-06-27  6:39 UTC (permalink / raw)
  To: Hans de Goede, Andy Shevchenko, Mauro Carvalho Chehab,
	Greg Kroah-Hartman
  Cc: Dan Carpenter, Sakari Ailus, linux-media, linux-staging,
	linux-kernel, 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


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH v2 2/2] media: atomisp: bound DVS 6-axis table dimensions to the allocated config
  2026-06-27  6:39 [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Doruk Tan Ozturk
  2026-06-27  6:39 ` [PATCH v2 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS Doruk Tan Ozturk
@ 2026-06-27  6:39 ` Doruk Tan Ozturk
  2026-06-27  7:57 ` [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Greg Kroah-Hartman
  2 siblings, 0 replies; 5+ messages in thread
From: Doruk Tan Ozturk @ 2026-06-27  6:39 UTC (permalink / raw)
  To: Hans de Goede, Andy Shevchenko, Mauro Carvalho Chehab,
	Greg Kroah-Hartman
  Cc: Dan Carpenter, Sakari Ailus, linux-media, linux-staging,
	linux-kernel, 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


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths
  2026-06-27  6:39 [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Doruk Tan Ozturk
  2026-06-27  6:39 ` [PATCH v2 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS Doruk Tan Ozturk
  2026-06-27  6:39 ` [PATCH v2 2/2] media: atomisp: bound DVS 6-axis table dimensions to the allocated config Doruk Tan Ozturk
@ 2026-06-27  7:57 ` Greg Kroah-Hartman
  2026-06-27 13:01   ` Doruk Tan Ozturk
  2 siblings, 1 reply; 5+ messages in thread
From: Greg Kroah-Hartman @ 2026-06-27  7:57 UTC (permalink / raw)
  To: Doruk Tan Ozturk
  Cc: Hans de Goede, Andy Shevchenko, Mauro Carvalho Chehab,
	Dan Carpenter, Sakari Ailus, linux-media, linux-staging,
	linux-kernel

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths
  2026-06-27  7:57 ` [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Greg Kroah-Hartman
@ 2026-06-27 13:01   ` Doruk Tan Ozturk
  0 siblings, 0 replies; 5+ messages in thread
From: Doruk Tan Ozturk @ 2026-06-27 13:01 UTC (permalink / raw)
  To: gregkh
  Cc: error27, hansg, andy, mchehab, sakari.ailus, linux-media,
	linux-staging, linux-kernel, Doruk Tan Ozturk

Hi Greg,

Done, just sent v3 with the Assisted-by tag, plus the Fixes tags and dropped
the comments per Dan. Thanks both!

Doruk

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-06-27 13:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-27  6:39 [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Doruk Tan Ozturk
2026-06-27  6:39 ` [PATCH v2 1/2] media: atomisp: validate sizeimage against the allocated frame in framebuffer-to-CSS Doruk Tan Ozturk
2026-06-27  6:39 ` [PATCH v2 2/2] media: atomisp: bound DVS 6-axis table dimensions to the allocated config Doruk Tan Ozturk
2026-06-27  7:57 ` [PATCH v2 0/2] media: atomisp: validate user-supplied buffer sizes in two ioctl paths Greg Kroah-Hartman
2026-06-27 13:01   ` Doruk Tan Ozturk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox