linux-kernel - Re: [PATCH v2] drm/i915: bounds check execbuffer relocation count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130311220059.GA18499@cantiga.alporthouse.com>
Date:	Mon, 11 Mar 2013 22:00:59 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Kees Cook <keescook@...omium.org>
Cc:	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org, jln@...gle.com,
	marcheu@...omium.org
Subject: Re: [PATCH v2] drm/i915: bounds check execbuffer relocation count

On Mon, Mar 11, 2013 at 02:23:29PM -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.

I'd keep the return value as EINVAL so that we can continue to
distinguish between the user passing garbage and hitting an oom. And
total_relocs is preferrable to total, which also leads us to think more
carefully about the error condition. I think the check should be against
INT_MAX / sizeof(struct reloc_entry) for consistency with our other
guard against overflows whilst allocating.
-Chris

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/