All of lore.kernel.org
 help / color / mirror / Atom feed
From: Todd Kjos <tkjos@google.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Todd Kjos <tkjos@android.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	selinux@vger.kernel.org,
	"open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>
Subject: Re: v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite
Date: Thu, 21 Mar 2019 08:48:18 -0700	[thread overview]
Message-ID: <CAHRSSEzktyn5uWdGobUKdkWLn8cwyQCbSo7C2vvn92EQvKciqw@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNv6N9YWOr13=+PfjUWa1QJ=GBJUbkBtxbqif1VgOUpNKA@mail.gmail.com>

On Thu, Mar 21, 2019 at 2:50 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Thu, Mar 21, 2019 at 12:26 AM Todd Kjos <tkjos@google.com> wrote:
> > I can send you a patch tomorrow (I won't be able to test it though).
>
> So, I was a bit quicker than you and I think I managed to fix the test myself :)
>
> See:
> https://github.com/SELinuxProject/selinux-testsuite/pull/50/commits/b559c3f54eae6130cb9e79c295b0f94db26e09e4

Looks good. Thanks!

>
> It seems the problem was indeed in the offsets array handling as you
> discovered. With the above commit included the PR#50 version of the
> binder test no longer fails for me.
>
> Thanks,
>
> >
> > On Wed, Mar 20, 2019 at 4:23 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Wed, Mar 20, 2019 at 3:50 PM Todd Kjos <tkjos@google.com> wrote:
> > > >
> > > > Paul,
> > > >
> > > > Looking at main() in test_binder.c...
> > > >
> > > > int main(int argc, char **argv)
> > > > {
> > > >
> > > > [...]
> > > >
> > > >   // Line 493
> > > >   struct binder_write_read bwr;
> > > >   struct flat_binder_object obj;
> > > >   struct {
> > > >     uint32_t cmd;
> > > >     struct binder_transaction_data txn;
> > > >   } __attribute__((packed)) writebuf;
> > > >   unsigned int readbuf[32];
> > > >
> > > > [...]
> > > >   // Line 630
> > > >   writebuf.txn.data.ptr.buffer = (uintptr_t)&obj;
> > > >   writebuf.txn.data.ptr.offsets = (uintptr_t)&obj +   // [A]
> > > >                                                  sizeof(struct
> > > > flat_binder_object);
> > > >
> > > >   bwr.write_buffer = (uintptr_t)&writebuf;
> > > >   bwr.write_size = sizeof(writebuf);
> > > >
> > > > It looks like bwr.txn.data.ptr.offsets points off the end of obj (see
> > > > [A] above), which means the binder driver will read compiler-dependent
> > > > stack data as the offset for the object. If it happens to be 0, then
> > > > the test will work (read the object from offset 0). If it's not 0,
> > > > then most likely offset > data_size (which is what found that BUG_ON
> > > > case). With my patch applied, this will just cause an error to be
> > > > returned (what you are seeing now).
> > > >
> > > > Same thing when you test with v5.0 -- if the offset happens to be 0,
> > > > then the test will succeed. If not, then the test will fail because
> > > > the transaction fails in an unexpected way.
> > >
> > > That might explain why the test used to work, but now fails - a
> > > different compiler (I rebuild the test before each test run).
> > >
> > > Keeping in mind I'm really quite ignorant when it comes to binder, how
> > > would you suggest fixing the test?
> > >
> > > --
> > > paul moore
> > > www.paul-moore.com
>
>
>
> --
> Ondrej Mosnacek <omosnace at redhat dot com>
> Software Engineer, Security Technologies
> Red Hat, Inc.

  reply	other threads:[~2019-03-21 15:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 21:31 v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite Paul Moore
2019-03-18 22:50 ` Todd Kjos
2019-03-18 23:02   ` Paul Moore
2019-03-19 16:50     ` Todd Kjos
2019-03-19 19:33       ` Paul Moore
2019-03-19 22:08         ` Paul Moore
2019-03-19 22:16           ` Todd Kjos
2019-03-19 22:20             ` Paul Moore
2019-03-20  0:15               ` Todd Kjos
2019-03-20  1:08                 ` Todd Kjos
2019-03-20  3:04                   ` Paul Moore
2019-03-20 15:54                     ` Todd Kjos
2019-03-20 19:50                       ` Todd Kjos
2019-03-20 20:06                         ` Todd Kjos
2019-03-20 23:23                         ` Paul Moore
2019-03-20 23:26                           ` Todd Kjos
2019-03-20 23:34                             ` Paul Moore
2019-03-21  9:50                             ` Ondrej Mosnacek
2019-03-21 15:48                               ` Todd Kjos [this message]
2019-03-21 20:24                                 ` Paul Moore
2019-03-20 22:25                       ` Paul Moore
2019-03-20 22:29                         ` Todd Kjos

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=CAHRSSEzktyn5uWdGobUKdkWLn8cwyQCbSo7C2vvn92EQvKciqw@mail.gmail.com \
    --to=tkjos@google.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=tkjos@android.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.