[syzbot] WARNING in binder_alloc_vma_close

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 08897940f458 Add linux-next specific files for 20220623
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=160dc3b0080000
kernel config: https://syzkaller.appspot.com/x/.config?x=fb185a52c6ad0a8e
dashboard link: https://syzkaller.appspot.com/bug?extid=da54fa8d793ca89c741f
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=14ef6974080000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13b9f0d4080000

The issue was bisected to:

commit 472a68df605b149ca58e931b4936e3136f5ecca0
Author: Liam R. Howlett <Liam.H...@oracle.com>
Date: Tue Jun 21 01:09:09 2022 +0000

android: binder: stop saving a pointer to the VMA

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=123596c4080000
final oops: https://syzkaller.appspot.com/x/report.txt?x=113596c4080000
console output: https://syzkaller.appspot.com/x/log.txt?x=163596c4080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+da54fa...@syzkaller.appspotmail.com
Fixes: 472a68df605b ("android: binder: stop saving a pointer to the VMA")

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3611 at include/linux/mmap_lock.h:161 mmap_assert_write_locked include/linux/mmap_lock.h:161 [inline]
WARNING: CPU: 0 PID: 3611 at include/linux/mmap_lock.h:161 binder_alloc_set_vma drivers/android/binder_alloc.c:323 [inline]
WARNING: CPU: 0 PID: 3611 at include/linux/mmap_lock.h:161 binder_alloc_vma_close+0x123/0x170 drivers/android/binder_alloc.c:970
Modules linked in:
CPU: 0 PID: 3611 Comm: syz-executor763 Not tainted 5.19.0-rc3-next-20220623-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mmap_assert_write_locked include/linux/mmap_lock.h:161 [inline]
RIP: 0010:binder_alloc_set_vma drivers/android/binder_alloc.c:323 [inline]
RIP: 0010:binder_alloc_vma_close+0x123/0x170 drivers/android/binder_alloc.c:970
Code: 5b fa 48 8d bd 58 01 00 00 31 f6 e8 d7 44 5d 02 31 ff 41 89 c4 89 c6 e8 7b f8 5b fa 45 85 e4 0f 85 5b ff ff ff e8 1d fc 5b fa <0f> 0b e9 4f ff ff ff e8 11 fc 5b fa 48 89 ef e8 99 cd 91 fa 0f 0b
RSP: 0018:ffffc90002dffbe0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff888078e119e0 RCX: 0000000000000000
RDX: ffff8880219d0000 RSI: ffffffff871ec183 RDI: 0000000000000005
RBP: ffff88807744c880 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: dffffc0000000000 R14: ffff88807744c880 R15: 0000000000000000
FS: 0000555556a5c300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6863e39130 CR3: 00000000217f4000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
remove_vma+0x81/0x130 mm/mmap.c:187
remove_mt mm/mmap.c:2232 [inline]
do_mas_align_munmap+0x9e6/0xef0 mm/mmap.c:2507
do_mas_munmap+0x202/0x2c0 mm/mmap.c:2562
__vm_munmap+0x159/0x290 mm/mmap.c:2833
__do_sys_munmap mm/mmap.c:2858 [inline]
__se_sys_munmap mm/mmap.c:2855 [inline]
__x64_sys_munmap+0x55/0x80 mm/mmap.c:2855
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f6863dc8099
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffdc69a2808 EFLAGS: 00000246 ORIG_RAX: 000000000000000b
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f6863dc8099
RDX: 00007f6863dc8099 RSI: 0000000000004000 RDI: 0000000020ffa000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000246 R12: 00007ffdc69a2850
R13: 00007ffdc69a2840 R14: 00007ffdc69a2830 R15: 0000000000000000
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Hillf Danton]

On Mon, 27 Jun 2022 00:20:21 -0700

See if it is due to a typo.

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 08897940f458

--- y/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -320,7 +320,7 @@ static inline void binder_alloc_set_vma(
alloc->vma_vm_mm = vma->vm_mm;
}

- mmap_assert_write_locked(alloc->vma_vm_mm);
+ mmap_assert_locked(alloc->vma_vm_mm);
alloc->vma_addr = vm_start;
}

--

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+da54fa...@syzkaller.appspotmail.com

Tested on:

commit: 08897940 Add linux-next specific files for 20220623
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=16ecb94c080000

kernel config: https://syzkaller.appspot.com/x/.config?x=fb185a52c6ad0a8e
dashboard link: https://syzkaller.appspot.com/bug?extid=da54fa8d793ca89c741f
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

patch: https://syzkaller.appspot.com/x/patch.diff?x=134bd9e4080000

Note: testing is done by a robot and is best-effort only.

[Liam Howlett]

* syzbot <syzbot+da54fa...@syzkaller.appspotmail.com> [220627 03:20]:

do_mas_align_munmap() may downgrade the lock. remove_vma is closing the
file - which binder is using to detect the removal of the vma. I think
the best plan here is to allow clearing the vma without asserting the
write lock. The read lock is still held so ensuring the read lock is
held is probably a worthy addition to the clearing path.