From: Mike Snitzer <snitzer@redhat.com>
To: Scotty Bauer <sbauer@eng.utah.edu>
Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org,
agk@redhat.com, jmoyer@redhat.com
Subject: Re: dm ioctl: Access user-land memory through safe functions.
Date: Wed, 6 Jan 2016 21:07:37 -0500 [thread overview]
Message-ID: <20160107020737.GA1658@redhat.com> (raw)
In-Reply-To: <568DBDDF.50708@eng.utah.edu>
On Wed, Jan 06 2016 at 8:22pm -0500,
Scotty Bauer <sbauer@eng.utah.edu> wrote:
>
>
> On 01/05/2016 02:13 PM, Mike Snitzer wrote:
> > On Tue, Jan 05 2016 at 3:16pm -0500,
> > Mike Snitzer <snitzer@redhat.com> wrote:
> >
> >> On Tue, Dec 08 2015 at 1:26pm -0500,
> >> Scotty Bauer <sbauer@eng.utah.edu> wrote:
> >>
> >>> Friendly ping, is anyone interested in this?
> >>
> >> The passed @user argument is flagged via __user so it can be
> >> deferenced directly. It does look like directly deferencing
> >> user->version is wrong.
> >>
> >> But even if such indirect access is needed (because __user flag is only
> >> applicable to @user arg, not the contained version member) we could more
> >> easily just do something like this no?:
> >>
> >> uint32_t __user *versionp = (uint32_t __user *)user->version;
> >> ...
> >> if (copy_from_user(version, versionp, sizeof(version)))
> >> return -EFAULT;
> >>
> >> I've staged the following, thanks:
> >> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.5&id=bffc9e237a0c3176712bcd93fc6a184a61e0df26
> >
> > Alasdair helped me understand that we do need your original fix.
> > I've staged it for 4.5 (and stable@) here:
> > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.5&id=ead3db62bf10fe143bec99e7b7ff370d7a6d23ef
> >
> > Thanks again,
> > Mike
> > --
>
> This broke linux-next because I'm dumb and didn't test it. I thought it was a trivial enough of a patch that I wouldn't screw it up, but I did.
>
> I incorrectly assumed that user->version was essentially a pointer in userland, not a flat chunk of memory. Ie it was a pointer to some malloc'd region, not an inlined version[3].
>
> I thought it was this:
> struct dm_ioctl {
>
> uint32_t *version;
> ...
> }
>
> It is really this:
>
> struct dm_ioctl {
>
> uint32_t version[3];
>
> }
>
> I was trying to get the values out of *version, which would have been a pointer, but instead what the code ended up doing was actually getting 8 bytes of the version (think 4,3,1) out and trying to access that version as a memory address, oops.
>
> It turns out that the original code is correct and doesn't actually touch user memory without a copy_from_user(). Gcc is smart enough to see that version[3] is inlined, and it can emit code which simply takes the userland pointer (struct dm_ioctl __user user), and calculates on offset based on the pointer, thus no actual user dereference occurs. Had the struct looked like the first example I believe the patch would work.
>
> I'm wondering now if we should switch the code a bit to make it less ambiguous, so someone like me doesn't come along again thinking the code dereferences userland memory and waste everyones time.
>
> I've attached a patch based off linux-next-20150616 which reverts my broken code but adds an & to the front of user->version so it looks like the code is doing the right thing.
>
> If I should be basing my patch off something other than linux-next let me know and I'll rewrite it, or we can just revert the old patch and ignore this one.
>
> Thanks and very sorry for the confusion and breakage.
You're fine, no worries.
But I've just dropped the offending original commit from linux-next and
it obviously won't be included in 4.5
I'll revisit whether we need to bother with the extra & change you're
suggesting while coming to terms with why I was able to be lulled into
thinking your original patch was correct ;)
prev parent reply other threads:[~2016-01-07 2:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 18:11 [PATCH] " Scotty
2015-12-08 18:26 ` Scotty Bauer
2016-01-05 20:16 ` Mike Snitzer
2016-01-05 21:13 ` Mike Snitzer
2016-01-07 1:22 ` Scotty Bauer
2016-01-07 2:07 ` Mike Snitzer [this message]
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=20160107020737.GA1658@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sbauer@eng.utah.edu \
/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
Powered by JetHome