Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752835AbdF0KPj (ORCPT ); Tue, 27 Jun 2017 06:15:39 -0400 Received: from fllnx209.ext.ti.com ([198.47.19.16]:14471 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752810AbdF0KOt (ORCPT ); Tue, 27 Jun 2017 06:14:49 -0400 Subject: Re: [PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck To: "Lad, Prabhakar" CC: Mauro Carvalho Chehab , Kevin Hilman , linux-media , LKML , Arnd Bergmann References: <20170609213616.410415-1-arnd@arndb.de> From: Sekhar Nori Message-ID: <1b0671fa-fec7-11fa-6b91-0afad904c651@ti.com> Date: Tue, 27 Jun 2017 15:43:45 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2205 Lines: 48 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. 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. Thanks, Sekhar