lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Nov 2021 12:11:29 -0800
From:   Todd Kjos <tkjos@...gle.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     gregkh@...uxfoundation.org, christian@...uner.io, arve@...roid.com,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        maco@...gle.com, joel@...lfernandes.org, kernel-team@...roid.com
Subject: Re: [PATCH 1/3] binder: avoid potential data leakage when copying txn

On Wed, Nov 24, 2021 at 5:01 AM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> On Tue, Nov 23, 2021 at 11:17:35AM -0800, Todd Kjos wrote:
> > Transactions are copied from the sender to the target
> > first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA
> > are then fixed up. This means there is a short period where
> > the sender's version of these objects are visible to the
> > target prior to the fixups.
> >
> > Instead of copying all of the data first, copy data only
> > after any needed fixups have been applied.
> >
>
> This patch needs a fixes tag.

Sure, it goes back to the original submission, so I'll add:

Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")

>
> So this patch basically fixes the simple part of the info leak and
> patch 3 fixes the complicated part.  Have I understood that correctly?

Yes.

>
> > @@ -2956,7 +2984,11 @@ static void binder_transaction(struct binder_proc *proc,
> >                       }
> >                       ret = binder_translate_fd_array(fda, parent, t, thread,
> >                                                       in_reply_to);
> > -                     if (ret < 0) {
> > +                     if (ret < 0 ||
> > +                         binder_alloc_copy_to_buffer(&target_proc->alloc,
> > +                                                     t->buffer,
> > +                                                     object_offset,
> > +                                                     fda, sizeof(*fda))) {
> >                               return_error = BR_FAILED_REPLY;
> >                               return_error_param = ret;
>
> "ret" is not a negative error code if binder_translate_fd_array()
> succeeds but binder_alloc_copy_to_buffer() fails.

You are right. return_error_param would be 0 in this case. Will
capture the return of binder_alloc_copy_to_buffer(). Thanks.

>
>
> >                               return_error_line = __LINE__;
> > @@ -3028,6 +3060,19 @@ static void binder_transaction(struct binder_proc *proc,
> >                       goto err_bad_object_type;
> >               }
> >       }
>
> regards,
> dan carpenter
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@...roid.com.
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ