Re: [syzbot] kernel BUG in binder_alloc_deferred_release

[Dmitry Vyukov]

On Tue, 21 Jun 2022 at 04:08, Liam Howlett <liam.howlett@xxxxxxxxxx> wrote:
>
> * syzbot <syzbot+58b51ac2b04e388ab7b0@xxxxxxxxxxxxxxxxxxxxxxxxx> [220619 21:47]:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    6012273897fe Add linux-next specific files for 20220615
> > git tree:       linux-next
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16596feff00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=b4154677977b1776
> > dashboard link: https://syzkaller.appspot.com/bug?extid=58b51ac2b04e388ab7b0
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1024e510080000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=113e407ff00000
> >
> > The issue was bisected to:
> >
> > commit 42086abba43463fbf495cb80173600284b4c4e8c
> > Author: Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
> > Date:   Tue Jun 14 19:00:27 2022 +0000
> >
> >     mm: start tracking VMAs with maple tree
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=10ef827ff00000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=12ef827ff00000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14ef827ff00000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:

Hi Liam,

Please also add the Reported-by tag.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/

> > Reported-by: syzbot+58b51ac2b04e388ab7b0@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Fixes: 42086abba434 ("mm: start tracking VMAs with maple tree")
> >
> > ------------[ cut here ]------------
> > kernel BUG at drivers/android/binder_alloc.c:820!
> > invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> > CPU: 0 PID: 2934 Comm: kworker/0:3 Not tainted 5.19.0-rc2-next-20220615-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Workqueue: events binder_deferred_func
> > RIP: 0010:binder_alloc_deferred_release+0x602/0x780 drivers/android/binder_alloc.c:820
> > Code: c6 80 16 c7 8a 48 c7 c7 80 b6 48 8d e8 57 86 05 fd 31 ff 89 c5 89 c6 e8 fc ba 5b fa 85 ed 74 c6 e9 78 57 55 02 e8 9e be 5b fa <0f> 0b c7 44 24 20 00 00 00 00 e9 27 ff ff ff e8 8a be 5b fa 48 89
> > RSP: 0018:ffffc9000de07bc8 EFLAGS: 00010293
> > RAX: 0000000000000000 RBX: ffff8880519971e0 RCX: 0000000000000000
> > RDX: ffff888026b0d7c0 RSI: ffffffff871f04b2 RDI: ffff888051997270
> > RBP: ffff888051997000 R08: 0000000000000000 R09: ffffffff8dbcac17
> > R10: fffffbfff1b79582 R11: 0000000000000000 R12: ffff888147653c60
> > R13: ffff8880519972d8 R14: ffff888147653d10 R15: dffffc0000000000
> > FS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f99ddec19c1 CR3: 0000000077a01000 CR4: 00000000003506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >  <TASK>
> >  binder_free_proc drivers/android/binder.c:4766 [inline]
>
> ...
>
>
> This task has alloc->vma set to a freed VMA.  What is happening is that
> I've added an allocation later in the mmap_region() code which is being
> failed by the fuzzer.  This failure means that the vma recorded in the
> binder code via the call_mmap() is going to be freed in the
> mmap_region() failure path, but the binder code does not know of the
> failure.
>
> I was going to move my preallocation above the call_mmap() to avoid this
> failure, but that will basically mask the issue(s) in binder.  There are
> two other possibilities that could cause the same binder failure.  The
> first being a rather unlikely arch_validate_flags() returning false.
> The second is a successful merge of the allocated VMA
> - also rare, but still possible.
>
> The code records a VMA to be used later and drops the mmap_lock.
> Shouldn't it record the *address* and look up the VMA when it is needed
> to avoid using a freed pointer?  There has been at least one other issue
> with recording the VMA [1].
>
> Anyways, the attached patch fixes the issue I've exposed by saving the
> start address and looking it up.  I've added lockdep checks for good
> measures.  It fixes the reproduces from this email, but may need more
> oversight.
>
>
> 1. https://lore.kernel.org/lkml/20190301230606.8302-1-tkjos@xxxxxxxxxx/
>
> Thanks,
> Liam
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@xxxxxxxxxxxxxxxx.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20220621020814.sjszxp3uz43rka62%40revolver.