Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391Ab3CNTcE (ORCPT ); Thu, 14 Mar 2013 15:32:04 -0400 Received: from mail-oa0-f44.google.com ([209.85.219.44]:50542 "EHLO mail-oa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750957Ab3CNTcC (ORCPT ); Thu, 14 Mar 2013 15:32:02 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130312003145.GA28993@www.outflux.net> <20130312090746.GD31324@cantiga.alporthouse.com> <20130313202858.GD1896@bremse> Date: Thu, 14 Mar 2013 12:32:00 -0700 X-Google-Sender-Auth: ykAhwkprpXJ8HfR2U_2EoBB7v-c Message-ID: Subject: Re: [PATCH v3] drm/i915: bounds check execbuffer relocation count From: Kees Cook To: Daniel Vetter Cc: Chris Wilson , LKML , David Airlie , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, Julien Tinnes , marcheu@chromium.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1659 Lines: 41 On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter wrote: > On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote: >> On Tue, Mar 12, 2013 at 09:07:46AM +0000, Chris Wilson wrote: >>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: >>> > It is possible to wrap the counter used to allocate the buffer for >>> > relocation copies. This could lead to heap writing overflows. >>> > >>> > CVE-2013-0913 >>> > >>> > v3: collapse test, improve comment >>> > v2: move check into validate_exec_list >>> > >>> > Signed-off-by: Kees Cook >>> > Reported-by: Pinkie Pie >>> > Cc: stable@vger.kernel.org >>> >>> Looks good to me. The only bikeshed that remains is whether we should >>> just collapse the two variables into one, but the current 'max - count' >>> is more idiomatic and so preferrable. >>> Reviewed-by: Chris Wilson >> >> Picked up for -fixes, thanks for the patch. > > I've forgotten to dump my wishlist: Can I have an i-g-t for this? For > this bug here specifically an execbuf with just one buffer with too > many relocs plus another execbuf with two buffers with relocation so > that the 2nd relocation list will overflow should be sufficient. Sure thing. Where do these live? (Or what docs should I read for this?) I'm assuming i-g-t means "intel graphics test"? :) -Kees -- Kees Cook Chrome OS Security -- 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/