v5.1-rc1 binder_alloc_do_buffer_copy() BUG_ON triggered by selinux-testsuite
Paul Moore
paul at paul-moore.com
Wed Mar 20 23:23:15 UTC 2019
On Wed, Mar 20, 2019 at 3:50 PM Todd Kjos <tkjos at 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
More information about the devel
mailing list