Re: [PATCH] binder: make sure fd closes complete
On Fri, Sep 3, 2021 at 1:06 AM Dan Carpenter wrote:
>
> On Thu, Sep 02, 2021 at 08:35:35AM -0700, Todd Kjos wrote:
> > On Tue, Aug 31, 2021 at 12:24 AM Martijn Coenen wrote:
> > >
> > > On Mon, Aug 30, 2021 at 9:51 PM 'Todd Kjos' via kernel-team
> > > wrote:
> > > >
> > > > During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
> > > > cleanup may close 1 or more fds. The close operations are
> > > > completed using the task work mechanism -- which means the thread
> > > > needs to return to userspace or the file object may never be
> > > > dereferenced -- which can lead to hung processes.
> > > >
> > > > Force the binder thread back to userspace if an fd is closed during
> > > > BC_FREE_BUFFER handling.
> > > >
> > > > Signed-off-by: Todd Kjos
> > > Reviewed-by: Martijn Coenen
> >
> > Please also add to stable releases 5.4 and later.
>
> It would be better if this had a fixes tag so we knew which is the first
> buggy commit.
>
> There was a long Project Zero article about the Bad Binder exploit
> because commit f5cb779ba163 ("ANDROID: binder: remove waitqueue when
> thread exits.") was marked as # 4.14 but it didn't have a Fixes tag and
> the actual buggy commit was in 4.9.
Good point Dan. I should have included a Fixes tag. Here is the tag
(issue introduced in 4.20):
Fixes: 80cd795630d6 ("binder: fix use-after-free due to ksys_close()
during fdget()")
Greg- would you like me to send a v2 with the Fixes tag and CC'ing
stable appropriately?
>
> regards,
> dan carpenter
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kernel-team+unsubscr...@android.com.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS 5d7d11dead3ea7191a8e8635fb718d0c3f203fe0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: 5d7d11dead3ea7191a8e8635fb718d0c3f203fe0 staging: r8188eu: remove unnecessary parentheses elapsed time: 730m configs tested: 145 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig i386 randconfig-c001-20210904 arm s3c6400_defconfig riscvalldefconfig arm cns3420vb_defconfig m68k bvme6000_defconfig sparc sparc32_defconfig powerpc mpc512x_defconfig arm axm55xx_defconfig powerpc mpc834x_itx_defconfig powerpc rainier_defconfig mips tb0226_defconfig m68km5272c3_defconfig mipsbcm63xx_defconfig arm socfpga_defconfig armspear6xx_defconfig powerpc mpc8560_ads_defconfig m68k amcore_defconfig sparc sparc64_defconfig xtensa iss_defconfig sh sh2007_defconfig arm colibri_pxa300_defconfig sh polaris_defconfig arm imx_v6_v7_defconfig mipsmaltaup_xpa_defconfig powerpc mpc83xx_defconfig arm at91_dt_defconfig ia64generic_defconfig powerpc katmai_defconfig arm nhk8815_defconfig arm hackkit_defconfig arm tct_hammer_defconfig arm ezx_defconfig powerpc tqm8548_defconfig armvt8500_v6_v7_defconfig armlart_defconfig sh ecovec24_defconfig sh rts7751r2dplus_defconfig powerpc makalu_defconfig mips capcella_defconfig powerpc sequoia_defconfig mips rbtx49xx_defconfig m68kmac_defconfig arm tegra_defconfig sh rsk7201_defconfig xtensageneric_kc705_defconfig pariscgeneric-32bit_defconfig arm exynos_defconfig x86_64allnoconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparc defconfig i386defconfig i386 allyesconfig sparcallyesconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a016-20210903 x86_64 randconfig-a011-20210903 x86_64 randconfig-a012-20210903 x86_64 randconfig-a015-20210903 x86_64 randconfig-a014-20210903 x86_64 randconfig-a013-20210903 i386 randconfig-a012-20210903 i386 randconfig-a015-20210903 i386 randconfig-a011-20210903 i386 randconfig-a013-20210903 i386 randconfig-a014-20210903 i386 randconfig-a016-20210903 arc randconfig-r043-20210904 riscvnommu_k210_defconfig riscvallyesconfig riscv
PROJECT SPONSORSHIP / LOANS AND INVESTMENT FINANCING
Greetings , I am contacting you to find out if you or your company need financing for your project / business? We have developed a new method of financing that does not take longer to receive financing from our clients. We are dedicated to project sponsorship, loan financing, project financing, financing investment, etc. If you are looking for funds to finance your project / Business or if you are willing to work as our agent in your country to find clients in need of financing and earn commissions, then get back to us with more details. I will share more with you once I get your response on its disposition. to secure our funding. Kind regards, Mr. Ibrahim Tafa GLOBAL INVESTMENT GROUP FZE, United Arab Emirates ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] binder: make sure fd closes complete
On Thu, Sep 02, 2021 at 08:35:35AM -0700, Todd Kjos wrote:
> On Tue, Aug 31, 2021 at 12:24 AM Martijn Coenen wrote:
> >
> > On Mon, Aug 30, 2021 at 9:51 PM 'Todd Kjos' via kernel-team
> > wrote:
> > >
> > > During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
> > > cleanup may close 1 or more fds. The close operations are
> > > completed using the task work mechanism -- which means the thread
> > > needs to return to userspace or the file object may never be
> > > dereferenced -- which can lead to hung processes.
> > >
> > > Force the binder thread back to userspace if an fd is closed during
> > > BC_FREE_BUFFER handling.
> > >
> > > Signed-off-by: Todd Kjos
> > Reviewed-by: Martijn Coenen
>
> Please also add to stable releases 5.4 and later.
It would be better if this had a fixes tag so we knew which is the first
buggy commit.
There was a long Project Zero article about the Bad Binder exploit
because commit f5cb779ba163 ("ANDROID: binder: remove waitqueue when
thread exits.") was marked as # 4.14 but it didn't have a Fixes tag and
the actual buggy commit was in 4.9.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
