All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Andy Whitcroft <robobotbotbot@gmail.com>,
	Brian Belleville <bbellevi@uci.edu>,
	Jiri Kosina <jikos@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl
Date: Thu, 20 Sep 2018 10:01:27 -0400	[thread overview]
Message-ID: <20180920140127.72w35olyd4ivnxjp@redhat.com> (raw)
In-Reply-To: <CAGXu5jLXm8mJuwtDEO_+dDJk5tRA+2mkEv5S9NaPP87J42B7KQ@mail.gmail.com>

On Mon, Aug 27, 2018 at 12:45:25AM -0700, Kees Cook wrote:
> On Tue, May 29, 2018 at 6:27 AM, Andy Whitcroft <robobotbotbot@gmail.com> wrote:
> > On Wed, Mar 07, 2018 at 04:02:45PM -0800, Brian Belleville wrote:
> >> The final field of a floppy_struct is the field "name", which is a
> >> pointer to a string in kernel memory. The kernel pointer should not be
> >> copied to user memory. The FDGETPRM ioctl copies a floppy_struct to
> >> user memory, including the "name" field. This pointer cannot be used
> >> by the user, and it will leak a kernel address to user-space, which
> >> will reveal the location of kernel code and data and undermine KASLR
> >> protection. Instead, copy the floppy_struct except for the "name"
> >> field.
> >>
> >> Signed-off-by: Brian Belleville <bbellevi@uci.edu>
> >> ---
> >>  drivers/block/floppy.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> >> index eae484a..4d4a422 100644
> >> --- a/drivers/block/floppy.c
> >> +++ b/drivers/block/floppy.c
> >> @@ -3470,6 +3470,7 @@ static int fd_locked_ioctl(struct block_device *bdev, fmode_t mode, unsigned int
> >>                                         (struct floppy_struct **)&outparam);
> >>               if (ret)
> >>                       return ret;
> >> +             size = offsetof(struct floppy_struct, name);
> >>               break;
> >>       case FDMSGON:
> >>               UDP->flags |= FTD_MSG;
> >
> > I am not sure it is reasonable to simply set size here to the length of the
> > valid data.  Though in the real world everyonne should be using the defines
> > and those should include the full length, the code itself does not require
> > this, it only prevents overly long reads.  So I think it is possible to do
> > this read with a shorter userspace buffer; with this change we would
> > then write beyond the end of the buffer.
> >
> > This also seems to introduce a slight behavioural difference between the
> > primary and compat calls.  The compat call already elides the name but it
> > also is copying into a new structure for return and this is pre-cleared,
> > so the name will always be null for the compat case and undefined for
> > the primary ioctl.
> >
> > Perhaps the below patch would be more appropriate.
> >
> > -apw
> >
> > From ddb8c77229a9507fa5575c910d2847e123a9c94c Mon Sep 17 00:00:00 2001
> > From: Andy Whitcroft <apw@canonical.com>
> > Date: Tue, 29 May 2018 13:04:15 +0100
> > Subject: [PATCH 1/1] floppy: Do not copy a kernel pointer to user memory in
> >  FDGETPRM ioctl
> >
> > The final field of a floppy_struct is the field "name", which is a pointer
> > to a string in kernel memory.  The kernel pointer should not be copied to
> > user memory.  The FDGETPRM ioctl copies a floppy_struct to user memory,
> > including this "name" field.  This pointer cannot be used by the user
> > and it will leak a kernel address to user-space, which will reveal the
> > location of kernel code and data and undermine KASLR protection.
> >
> > Model this code after the compat ioctl which copies the returned data
> > to a previously cleared temporary structure on the stack (excluding the
> > name pointer) and copy out to userspace from there.  As we already have
> > an inparam union with an appropriate member and that memory is already
> > cleared even for read only calls make use of that as a temporary store.
> >
> > Based on an initial patch by Brian Belleville.
> >
> > CVE-2018-7755
> > Signed-off-by: Andy Whitcroft <apw@canonical.com>
> 
> I didn't see this land anywhere? Who's tree is this going through?
> 
> -Kees
> 

Looks like a pretty simple fix, but still don't see this one anywhere...
maybe Jiri or Jens could pick it up (as per get_maintainer output :)

-- Joe

> > ---
> >  drivers/block/floppy.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> > index 8ec7235fc93b..7512f6ff7c43 100644
> > --- a/drivers/block/floppy.c
> > +++ b/drivers/block/floppy.c
> > @@ -3470,6 +3470,8 @@ static int fd_locked_ioctl(struct block_device *bdev, fmode_t mode, unsigned int
> >                                           (struct floppy_struct **)&outparam);
> >                 if (ret)
> >                         return ret;
> > +               memcpy(&inparam.g, outparam, offsetof(struct floppy_struct, name));
> > +               outparam = &inparam.g;
> >                 break;
> >         case FDMSGON:
> >                 UDP->flags |= FTD_MSG;
> > --
> > 2.17.0
> >
> 
> 
> 
> -- 
> Kees Cook
> Pixel Security

  reply	other threads:[~2018-09-20 14:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08  0:02 [PATCH] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl Brian Belleville
2018-03-22 19:59 ` Brian Belleville
2018-05-29 13:27 ` Andy Whitcroft
2018-07-09 23:14   ` Ben Hutchings
2018-08-27  7:45   ` Kees Cook
2018-09-20 14:01     ` Joe Lawrence [this message]
2018-09-20 15:10       ` Jens Axboe

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=20180920140127.72w35olyd4ivnxjp@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bbellevi@uci.edu \
    --cc=jikos@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robobotbotbot@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.