[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220621020814.sjszxp3uz43rka62@revolver>
Date: Tue, 21 Jun 2022 02:08:22 +0000
From: Liam Howlett <liam.howlett@...cle.com>
To: syzbot <syzbot+58b51ac2b04e388ab7b0@...kaller.appspotmail.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"arve@...roid.com" <arve@...roid.com>,
"brauner@...nel.org" <brauner@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"hridya@...gle.com" <hridya@...gle.com>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"maco@...roid.com" <maco@...roid.com>,
"surenb@...gle.com" <surenb@...gle.com>,
"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
"tkjos@...roid.com" <tkjos@...roid.com>,
"willy@...radead.org" <willy@...radead.org>,
"minchan@...nel.org" <minchan@...nel.org>
Subject: Re: [syzbot] kernel BUG in binder_alloc_deferred_release
* syzbot <syzbot+58b51ac2b04e388ab7b0@...kaller.appspotmail.com> [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@...cle.com>
> 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:
> Reported-by: syzbot+58b51ac2b04e388ab7b0@...kaller.appspotmail.com
> 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@google.com/
Thanks,
Liam
View attachment "0001-android-binder-Stop-saving-a-pointer-to-the-VMA.patch" of type "text/x-diff" (3734 bytes)
Powered by blists - more mailing lists