Hi Arnd, On Tue, Jun 27, 2017 at 12:08 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tue, Jun 27, 2017 at 12:13 PM, Sekhar Nori <nsekhar@xxxxxx> wrote: >> On Tuesday 20 June 2017 06:36 PM, Lad, Prabhakar wrote: >>> Hi Arnd, >>> >>> Thanks for the patch. >>> >>> On Fri, Jun 9, 2017 at 10:36 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>>> Now that the davinci drivers can be enabled in compile tests on other >>>> architectures, I ran into this warning on a 64-bit build: >>>> >>>> drivers/media/platform/davinci/dm644x_ccdc.c: In function 'ccdc_update_raw_params': >>>> drivers/media/platform/davinci/dm644x_ccdc.c:279:7: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] >>>> >>>> While that looks fairly harmless (it would be fine on 32-bit), it was >>>> just the tip of the iceberg: >>>> >>>> - The function constantly mixes up pointers and phys_addr_t numbers >>>> - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is >>>> described as an 'experimental ioctl that will change in future kernels', >>>> but if we have users that probably won't happen. >>>> - The code to allocate the table never gets called after we copy_from_user >>>> the user input over the kernel settings, and then compare them >>>> for inequality. >>>> - We then go on to use an address provided by user space as both the >>>> __user pointer for input and pass it through phys_to_virt to come up >>>> with a kernel pointer to copy the data to. This looks like a trivially >>>> exploitable root hole. >>>> >>>> This patch disables all the obviously broken code, by zeroing out the >>>> sensitive data provided by user space. I also fix the type confusion >>>> here. If we think the ioctl has no stable users, we could consider >>>> just removing it instead. >>>> >>> I suspect there shouldn’t be possible users of this IOCTL, better of removing >>> the IOCTL itself. >>> >>> Sekhar your call, as the latest PSP releases for 644x use the media >>> controller framework. >> >> I do not have any personal experience with anyone using this support >> with latest kernels. I too am okay with removing the broken support. > > Ok, I think that would be good. Can one of you create that patch? > Note that we have two implementations of the ioctl, with different > data structures, depending on the specific hardware. > I have posted a patch on top of yours. Acked-by: Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx> >> Since the header file that defines the ioctl is not in include/uapi/*, I >> guess it cannot be considered stable userspace ABI? Also, there are >> enough warnings about instability thrown in the comments surrounding the >> ioctl in include/media/davinci/vpfe_capture.h. > > This is not relevant really. The only thing that counts is whether there > is existing user space that has active users who complain if it breaks. > > If you think nobody is using it, that is more important than code > comments or the location of the header file, but if someone complains > later anyway, we may end up reverting the removal and fix it differently. > Agreed. Cheers, --Prabhakar Lad
