From: Greg KH <gregkh@linuxfoundation.org>
To: Ashwin H <ashwinh@vmware.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@kernel.org" <stable@kernel.org>,
Srivatsa Bhat <srivatsab@vmware.com>,
"srivatsa@csail.mit.edu" <srivatsa@csail.mit.edu>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
Steven Rostedt <srostedt@vmware.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
Date: Wed, 27 May 2020 17:31:30 +0200 [thread overview]
Message-ID: <20200527153130.GA525531@kroah.com> (raw)
In-Reply-To: <MN2PR05MB63814CDAAF6828285929736ACDBF0@MN2PR05MB6381.namprd05.prod.outlook.com>
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 :(
See:
https://lore.kernel.org/r/20200527140225.GA214763@roeck-us.net
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?
thanks,
greg k-h
next prev parent reply other threads:[~2020-05-27 15:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 1:49 [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' ashwin-h
2020-05-13 5:55 ` Greg KH
2020-05-13 6:13 ` Ashwin H
2020-05-13 6:34 ` Greg KH
2020-05-13 17:08 ` Ashwin H
2020-05-27 15:31 ` Greg KH [this message]
2020-05-28 7:30 ` Ashwin H
2020-05-28 11:20 ` Ashwin H
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200527153130.GA525531@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=ashwinh@vmware.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=srivatsa@csail.mit.edu \
--cc=srivatsab@vmware.com \
--cc=srostedt@vmware.com \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox