CVE-2022-49947

In the Linux kernel, the following vulnerability has been resolved:

binder: fix alloc->vmavmmm null-ptr dereference

Syzbot reported a couple issues introduced by commit 44e602b4e52f ("binderalloc: add missing mmaplock calls when using the VMA"), in which we attempt to acquire the mmaplock when alloc->vmavm_mm has not been initialized yet.

This can happen if a binderproc receives a transaction without having previously called mmap() to setup the binderproc->alloc space in [1]. Also, a similar issue occurs via binderallocprint_pages() when we try to dump the debugfs binder stats file in [2].

Sample of syzbot's crash report: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 RIP: 0010:_lockacquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Call Trace: <TASK> lockacquire kernel/locking/lockdep.c:5666 [inline] lockacquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 downread+0x98/0x450 kernel/locking/rwsem.c:1499 mmapreadlock include/linux/mmaplock.h:117 [inline] binderallocnewbuflocked drivers/android/binderalloc.c:405 [inline] binderallocnewbuf+0xa5/0x19e0 drivers/android/binderalloc.c:593 bindertransaction+0x242e/0x9a80 drivers/android/binder.c:3199 binderthreadwrite+0x664/0x3220 drivers/android/binder.c:3986 binderioctlwriteread drivers/android/binder.c:5036 [inline] binderioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x193/0x200 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd [...] ==================================================================

Fix these issues by setting up alloc->vmavmmm pointer during open() and caching directly from current->mm. This guarantees we have a valid reference to take the mmap_lock during scenarios described above.

[1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9