[PATCH v3 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, 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