On Fri, Jul 10, 2020 at 8:54 AM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jul 10, 2020 at 12:39:48AM +0200, Jann Horn wrote: > > Binder is designed such that a binder_proc never has references to > > itself. If this rule is violated, memory corruption can occur when a > > process sends a transaction to itself; see e.g. > > <https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>. > > > > There is a remaining edgecase through which such a transaction-to-self > > can still occur from the context of a task with BINDER_SET_CONTEXT_MGR > > access: > > > > - task A opens /dev/binder twice, creating binder_proc instances P1 > > and P2 > > - P1 becomes context manager > > - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its > > handle table > > - P1 dies (by closing the /dev/binder fd and waiting a bit) > > - P2 becomes context manager > > - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its > > handle table > > [this triggers a warning: "binder: 1974:1974 tried to acquire > > reference to desc 0, got 1 instead"] > > - task B opens /dev/binder once, creating binder_proc instance P3 > > - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way > > transaction) > > - P2 receives the handle and uses it to call P3 (two-way transaction) > > - P3 calls P2 (via magic handle 0) (two-way transaction) > > - P2 calls P2 (via handle 1) (two-way transaction) > > > > And then, if P2 does *NOT* accept the incoming transaction work, but > > instead closes the binder fd, we get a crash. > > > > Solve it by preventing the context manager from using ACQUIRE on ref 0. > > There shouldn't be any legitimate reason for the context manager to do > > that. > > > > Additionally, print a warning if someone manages to find another way to > > trigger a transaction-to-self bug in the future. > > > > Cc: stable@xxxxxxxxxxxxxxx > > Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") > > Signed-off-by: Jann Horn <jannh@xxxxxxxxxx> > > Acked-by: Todd Kjos <tkjos@xxxxxxxxxx> > > --- > > sending again because I forgot to CC LKML the first time... sorry about > > the spam. > > This spits out a bunch of warnings when built, how did it work on your > end? ... by creating the patch file before fixing the warnings. Sigh. I'll send the proper patch as v2... _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
