media: atomisp: validate user-supplied buffer sizes in two ioctl paths

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