> -----Original Message----- > From: Ashwin H > Sent: Thursday, May 28, 2020 1:01 PM > To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Cc: x86@xxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel- > gfx@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxx; > Srivatsa Bhat <srivatsab@xxxxxxxxxx>; srivatsa@xxxxxxxxxxxxx; > rostedt@xxxxxxxxxxx; Steven Rostedt <srostedt@xxxxxxxxxx>; Linus > Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > Subject: RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > > > > -----Original Message----- > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > > Sent: Wednesday, May 27, 2020 9:02 PM > > To: Ashwin H <ashwinh@xxxxxxxxxx> > > Cc: x86@xxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel- > > gfx@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > stable@xxxxxxxxxx; Srivatsa Bhat <srivatsab@xxxxxxxxxx>; > > srivatsa@xxxxxxxxxxxxx; rostedt@xxxxxxxxxxx; Steven Rostedt > > <srostedt@xxxxxxxxxx>; Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > 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 > > wrong. > > > > > > 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. > Build results: > total: 155 pass: 155 fail: 0 > Qemu test results: > total: 421 pass: 390 fail: 31 > Failed tests: > <all alpha> > <all sh> > <all sheb> > > > See: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F > > %2Flore.kernel.org%2Fr%2F20200527140225.GA214763%40roeck- > > > us.net&data=02%7C01%7Cashwinh%40vmware.com%7Cd8f60bb8a4584 > > > 7caa10f08d802530997%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7 > > > C637261902960990057&sdata=Vjv9v0QhebfcOGSq1UUDKshTDA%2FOV > > 4aKbqzKKJkEQxM%3D&reserved=0 > > 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. This seems to be the issue in alpha and SH https://lore.kernel.org/lkml/6a4fe075-a644-1b06-305b-9e55b8c9575b@xxxxxxxxxxxx/#t alpha and SH had buggy implementation of access_ok Thanks, Ashwin > > > thanks, > > > > greg k-h > > Thanks, > Ashwin _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
