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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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