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@xxxxxxxxx> 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
>
>