Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751746AbdF3Jhk (ORCPT ); Fri, 30 Jun 2017 05:37:40 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:34532 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668AbdF3Jhh (ORCPT ); Fri, 30 Jun 2017 05:37:37 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170609213616.410415-1-arnd@arndb.de> <1b0671fa-fec7-11fa-6b91-0afad904c651@ti.com> From: "Lad, Prabhakar" Date: Fri, 30 Jun 2017 10:37:06 +0100 Message-ID: Subject: Re: [PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck To: Arnd Bergmann Cc: Sekhar Nori , Mauro Carvalho Chehab , Kevin Hilman , linux-media , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v5U9bkxr013818 Content-Length: 3128 Lines: 69 Hi Arnd, On Tue, Jun 27, 2017 at 12:08 PM, Arnd Bergmann wrote: > On Tue, Jun 27, 2017 at 12:13 PM, Sekhar Nori 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 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 >> 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