Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932750Ab3CQVvw (ORCPT ); Sun, 17 Mar 2013 17:51:52 -0400 Received: from mga14.intel.com ([143.182.124.37]:56543 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932510Ab3CQVvu (ORCPT ); Sun, 17 Mar 2013 17:51:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,860,1355126400"; d="scan'208";a="215766572" Date: Sun, 17 Mar 2013 21:51:42 +0000 From: Chris Wilson To: Dave Airlie Cc: Daniel Vetter , Ben Widawsky , Tommi Rantala , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Dave Jones Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer Message-ID: <20130317215142.GC26102@cantiga.alporthouse.com> Mail-Followup-To: Chris Wilson , Dave Airlie , Daniel Vetter , Ben Widawsky , Tommi Rantala , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Dave Jones References: <1363265997-29023-1-git-send-email-chris@chris-wilson.co.uk> <20130315045004.GA14747@bwidawsk.net> <20130315082403.GA29916@cantiga.alporthouse.com> <20130315163606.GA17773@bwidawsk.net> <20130315220619.GA17405@cantiga.alporthouse.com> <20130315234942.GB715@bwidawsk.net> <20130316101920.GB17405@cantiga.alporthouse.com> <20130317214049.GB26102@cantiga.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1889 Lines: 44 On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote: > On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson wrote: > > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote: > >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson wrote: > >> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl > >> > command (which are seperate from the ioctl number), then kdata is set to > >> > NULL. > >> > >> Doesn't that mean that we need these checks everywhere? Or at least a > >> fixup in drm core proper? > > > > That's my conclusion. We either add a flag to ask drm_ioctl to prevent > > passing NULL pointers (as the existing behaviour may be useful > > somewhere, and I have not checked all callees) or saturate our callbacks > > with NULL checks. > > Do we have the kernel's expected IOC_IN/IOC_OUT flags at that point as well? > > we could check them and block NULL in that case. Yes. For the core ioctls, we use drm_ioctls[nr].cmd rather than the value passed in by userspace for the IOC_IN|IN_OUT bits. So: diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 25f91cd..79b8bd1 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -408,6 +408,7 @@ long drm_ioctl(struct file *filp, usize = asize = _IOC_SIZE(cmd); if (drv_size > asize) asize = drv_size; + cmd = ioctl->cmd; } else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) { ioctl = &drm_ioctls[nr]; -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/