[Intel-gfx] [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
ashwinh at vmware.com
Thu May 28 07:30:30 UTC 2020
> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Wednesday, May 27, 2020 9:02 PM
> To: Ashwin H <ashwinh at vmware.com>
> Cc: x86 at kernel.org; dri-devel at lists.freedesktop.org; intel-
> gfx at lists.freedesktop.org; linux-kernel at vger.kernel.org; stable at kernel.org;
> Srivatsa Bhat <srivatsab at vmware.com>; srivatsa at csail.mit.edu;
> rostedt at goodmis.org; Steven Rostedt <srostedt at vmware.com>; Linus
> Torvalds <torvalds at linux-foundation.org>
> Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> On Wed, May 13, 2020 at 05:08:19PM +0000, Ashwin H wrote:
> > > Ok, but what does that mean for us?
> > >
> > > You need to say why you are sending a patch, otherwise we will guess
> > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does
> user_access_begin() without doing access_ok(Checks if a user space pointer
> is valid) first.
> > A local attacker can craft a malicious ioctl function call to
> > overwrite arbitrary kernel memory, resulting in a Denial of Service or
> > privilege escalation (CVE-2018-20669)
> > This patch makes sure that user_access_begin always does access_ok.
> > user_access_begin has been modified to do access_ok internally.
> I had this in the tree, but it broke the build on alpha, sh, and maybe a few
> others :(
Thanks Greg for including this patch.
I am sorry that this patch caused the failure. As I see this is not a build failure but tests have failed.
total: 155 pass: 155 fail: 0
Qemu test results:
total: 421 pass: 390 fail: 31
> for the details.
> Can you dig out all of the needed follow-on patches as well, and send them
> all as a patch series for 4.19.y so that I can queue them all up at once?
I will check for follow-on patches and get back.
> greg k-h
More information about the Intel-gfx