2022-11-30 04:49:22

by Carlos Llamas

[permalink] [raw]
Subject: [PATCH 5.10 0/6] binder: backports for data leak and UAF

This series of backports consists of 3 main patches from Todd submitted
upstream in [1]. The intention is to avoid untranslated data from the
senders to be visible to the target processes. More details of this
issue can be found in the same thread.

Furthermore, Todd's patches also fix a use-after-free issue introduced
by commit 32e9f56a96d8 ("binder: don't detect sender/target during
buffer cleanup"). In which invalid userspace input causes unprocessed
objects to be incorrectly released. Any subsequent references to these
objects will trigger a UAF as noted by the following KASAN trace:

[ 244.748468] ==================================================================
[ 244.750486] BUG: KASAN: use-after-free in binder_ioctl+0xb88/0x32e0
[ 244.751276] Read of size 8 at addr ffff67b1865bea58 by task poc/593
[ 244.752074]
[ 244.752725] CPU: 0 PID: 593 Comm: poc Not tainted 5.10.156 #1
[ 244.753683] Hardware name: linux,dummy-virt (DT)
[ 244.754717] Call trace:
[ 244.755216] dump_backtrace+0x0/0x2a0
[ 244.755836] show_stack+0x18/0x2c
[ 244.756306] dump_stack+0xf8/0x164
[ 244.756807] print_address_description.constprop.0+0x9c/0x538
[ 244.757590] kasan_report+0x120/0x200
[ 244.758236] __asan_load8+0xa0/0xc4
[ 244.758756] binder_ioctl+0xb88/0x32e0
[ 244.759283] __arm64_sys_ioctl+0xd4/0x120
[ 244.759677] el0_svc_common.constprop.0+0xac/0x270
[ 244.760184] do_el0_svc+0x38/0xa0
[ 244.760540] el0_svc+0x1c/0x2c
[ 244.760898] el0_sync_handler+0xe8/0x114
[ 244.761419] el0_sync+0x180/0x1c0

This second issue along with the reference to the commit fixing it was
first reported by Zi Fan.

The other 3 commits included in this series are simply upstream fixes
for the main patches.

I've tested this series applied to 5.10 and 5.4 which fixes the issues
above as expected. So please pick these up for 5.10 and 5.4 stable.

[1] https://lore.kernel.org/all/[email protected]/

Thanks,
Carlos Llamas

Cc: Zi Fan Tan <[email protected]>
Cc: Todd Kjos <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>

Alessandro Astone (2):
binder: Address corner cases in deferred copy and fixup
binder: Gracefully handle BINDER_TYPE_FDA objects with num_fds=0

Arnd Bergmann (1):
binder: fix pointer cast warning

Todd Kjos (3):
binder: avoid potential data leakage when copying txn
binder: read pre-translated fds from sender buffer
binder: defer copies of pre-patched txn data

drivers/android/binder.c | 437 ++++++++++++++++++++++++++++++++++-----
1 file changed, 383 insertions(+), 54 deletions(-)

--
2.38.1.584.g0f3c55d4c2-goog


2022-11-30 13:09:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 0/6] binder: backports for data leak and UAF

On Wed, Nov 30, 2022 at 03:57:59AM +0000, Carlos Llamas wrote:
> This series of backports consists of 3 main patches from Todd submitted
> upstream in [1]. The intention is to avoid untranslated data from the
> senders to be visible to the target processes. More details of this
> issue can be found in the same thread.
>
> Furthermore, Todd's patches also fix a use-after-free issue introduced
> by commit 32e9f56a96d8 ("binder: don't detect sender/target during
> buffer cleanup"). In which invalid userspace input causes unprocessed
> objects to be incorrectly released. Any subsequent references to these
> objects will trigger a UAF as noted by the following KASAN trace:
>
> [ 244.748468] ==================================================================
> [ 244.750486] BUG: KASAN: use-after-free in binder_ioctl+0xb88/0x32e0
> [ 244.751276] Read of size 8 at addr ffff67b1865bea58 by task poc/593
> [ 244.752074]
> [ 244.752725] CPU: 0 PID: 593 Comm: poc Not tainted 5.10.156 #1
> [ 244.753683] Hardware name: linux,dummy-virt (DT)
> [ 244.754717] Call trace:
> [ 244.755216] dump_backtrace+0x0/0x2a0
> [ 244.755836] show_stack+0x18/0x2c
> [ 244.756306] dump_stack+0xf8/0x164
> [ 244.756807] print_address_description.constprop.0+0x9c/0x538
> [ 244.757590] kasan_report+0x120/0x200
> [ 244.758236] __asan_load8+0xa0/0xc4
> [ 244.758756] binder_ioctl+0xb88/0x32e0
> [ 244.759283] __arm64_sys_ioctl+0xd4/0x120
> [ 244.759677] el0_svc_common.constprop.0+0xac/0x270
> [ 244.760184] do_el0_svc+0x38/0xa0
> [ 244.760540] el0_svc+0x1c/0x2c
> [ 244.760898] el0_sync_handler+0xe8/0x114
> [ 244.761419] el0_sync+0x180/0x1c0
>
> This second issue along with the reference to the commit fixing it was
> first reported by Zi Fan.
>
> The other 3 commits included in this series are simply upstream fixes
> for the main patches.
>
> I've tested this series applied to 5.10 and 5.4 which fixes the issues
> above as expected. So please pick these up for 5.10 and 5.4 stable.
>
> [1] https://lore.kernel.org/all/[email protected]/
>
> Thanks,
> Carlos Llamas
>
> Cc: Zi Fan Tan <[email protected]>
> Cc: Todd Kjos <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>

All now queued up, thanks.

greg k-h

2022-11-30 16:56:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 0/6] binder: backports for data leak and UAF

On Wed, Nov 30, 2022 at 04:12:59PM +0000, Carlos Llamas wrote:
> On Wed, Nov 30, 2022 at 01:42:23PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Nov 30, 2022 at 03:57:59AM +0000, Carlos Llamas wrote:
> > > This series of backports consists of 3 main patches from Todd submitted
> > > upstream in [1]. The intention is to avoid untranslated data from the
> > > senders to be visible to the target processes. More details of this
> > > issue can be found in the same thread.
> > >
> > > Furthermore, Todd's patches also fix a use-after-free issue introduced
> > > by commit 32e9f56a96d8 ("binder: don't detect sender/target during
> > > buffer cleanup"). In which invalid userspace input causes unprocessed
> > > objects to be incorrectly released. Any subsequent references to these
> > > objects will trigger a UAF as noted by the following KASAN trace:
> > >
> > > [ 244.748468] ==================================================================
> > > [ 244.750486] BUG: KASAN: use-after-free in binder_ioctl+0xb88/0x32e0
> > > [ 244.751276] Read of size 8 at addr ffff67b1865bea58 by task poc/593
> > > [ 244.752074]
> > > [ 244.752725] CPU: 0 PID: 593 Comm: poc Not tainted 5.10.156 #1
> > > [ 244.753683] Hardware name: linux,dummy-virt (DT)
> > > [ 244.754717] Call trace:
> > > [ 244.755216] dump_backtrace+0x0/0x2a0
> > > [ 244.755836] show_stack+0x18/0x2c
> > > [ 244.756306] dump_stack+0xf8/0x164
> > > [ 244.756807] print_address_description.constprop.0+0x9c/0x538
> > > [ 244.757590] kasan_report+0x120/0x200
> > > [ 244.758236] __asan_load8+0xa0/0xc4
> > > [ 244.758756] binder_ioctl+0xb88/0x32e0
> > > [ 244.759283] __arm64_sys_ioctl+0xd4/0x120
> > > [ 244.759677] el0_svc_common.constprop.0+0xac/0x270
> > > [ 244.760184] do_el0_svc+0x38/0xa0
> > > [ 244.760540] el0_svc+0x1c/0x2c
> > > [ 244.760898] el0_sync_handler+0xe8/0x114
> > > [ 244.761419] el0_sync+0x180/0x1c0
> > >
> > > This second issue along with the reference to the commit fixing it was
> > > first reported by Zi Fan.
> > >
> > > The other 3 commits included in this series are simply upstream fixes
> > > for the main patches.
> > >
> > > I've tested this series applied to 5.10 and 5.4 which fixes the issues
> > > above as expected. So please pick these up for 5.10 and 5.4 stable.
> > >
> > > [1] https://lore.kernel.org/all/[email protected]/
> > >
> > > Thanks,
> > > Carlos Llamas
> > >
> > > Cc: Zi Fan Tan <[email protected]>
> > > Cc: Todd Kjos <[email protected]>
> > > Cc: Greg Kroah-Hartman <[email protected]>
> >
> > All now queued up, thanks.
> >
> > greg k-h
>
> Thanks Greg. Could you also take this series for 5.4? I've also tested
> the fixes for that release.

Sure, all now queued up there too.

greg k-h

2022-11-30 17:34:49

by Carlos Llamas

[permalink] [raw]
Subject: Re: [PATCH 5.10 0/6] binder: backports for data leak and UAF

On Wed, Nov 30, 2022 at 01:42:23PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Nov 30, 2022 at 03:57:59AM +0000, Carlos Llamas wrote:
> > This series of backports consists of 3 main patches from Todd submitted
> > upstream in [1]. The intention is to avoid untranslated data from the
> > senders to be visible to the target processes. More details of this
> > issue can be found in the same thread.
> >
> > Furthermore, Todd's patches also fix a use-after-free issue introduced
> > by commit 32e9f56a96d8 ("binder: don't detect sender/target during
> > buffer cleanup"). In which invalid userspace input causes unprocessed
> > objects to be incorrectly released. Any subsequent references to these
> > objects will trigger a UAF as noted by the following KASAN trace:
> >
> > [ 244.748468] ==================================================================
> > [ 244.750486] BUG: KASAN: use-after-free in binder_ioctl+0xb88/0x32e0
> > [ 244.751276] Read of size 8 at addr ffff67b1865bea58 by task poc/593
> > [ 244.752074]
> > [ 244.752725] CPU: 0 PID: 593 Comm: poc Not tainted 5.10.156 #1
> > [ 244.753683] Hardware name: linux,dummy-virt (DT)
> > [ 244.754717] Call trace:
> > [ 244.755216] dump_backtrace+0x0/0x2a0
> > [ 244.755836] show_stack+0x18/0x2c
> > [ 244.756306] dump_stack+0xf8/0x164
> > [ 244.756807] print_address_description.constprop.0+0x9c/0x538
> > [ 244.757590] kasan_report+0x120/0x200
> > [ 244.758236] __asan_load8+0xa0/0xc4
> > [ 244.758756] binder_ioctl+0xb88/0x32e0
> > [ 244.759283] __arm64_sys_ioctl+0xd4/0x120
> > [ 244.759677] el0_svc_common.constprop.0+0xac/0x270
> > [ 244.760184] do_el0_svc+0x38/0xa0
> > [ 244.760540] el0_svc+0x1c/0x2c
> > [ 244.760898] el0_sync_handler+0xe8/0x114
> > [ 244.761419] el0_sync+0x180/0x1c0
> >
> > This second issue along with the reference to the commit fixing it was
> > first reported by Zi Fan.
> >
> > The other 3 commits included in this series are simply upstream fixes
> > for the main patches.
> >
> > I've tested this series applied to 5.10 and 5.4 which fixes the issues
> > above as expected. So please pick these up for 5.10 and 5.4 stable.
> >
> > [1] https://lore.kernel.org/all/[email protected]/
> >
> > Thanks,
> > Carlos Llamas
> >
> > Cc: Zi Fan Tan <[email protected]>
> > Cc: Todd Kjos <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
>
> All now queued up, thanks.
>
> greg k-h

Thanks Greg. Could you also take this series for 5.4? I've also tested
the fixes for that release.

--
Carlos Llamas