[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN2PR05MB63814CDAAF6828285929736ACDBF0@MN2PR05MB6381.namprd05.prod.outlook.com>
Date: Wed, 13 May 2020 17:08:19 +0000
From: Ashwin H <ashwinh@...are.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "x86@...nel.org" <x86@...nel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...nel.org" <stable@...nel.org>,
Srivatsa Bhat <srivatsab@...are.com>,
"srivatsa@...il.mit.edu" <srivatsa@...il.mit.edu>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
Steven Rostedt <srostedt@...are.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> 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.
Thanks,
Ashwin
Powered by blists - more mailing lists