From nobody Tue Apr 7 10:37:52 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E207ECAAD2 for ; Mon, 29 Aug 2022 20:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230107AbiH2UNI (ORCPT ); Mon, 29 Aug 2022 16:13:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230095AbiH2UNC (ORCPT ); Mon, 29 Aug 2022 16:13:02 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 995B17677D for ; Mon, 29 Aug 2022 13:13:00 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id m5-20020a170902f64500b0016d313f3ce7so6782522plg.23 for ; Mon, 29 Aug 2022 13:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc; bh=3+KFGw/lw7UFTEKp2QYuhuNuaZRNkMlHXcRjkBPuoco=; b=KkqpTJCgR/OwOt0P10HqU41mOPMq7h05KJQ8hIf3ml9CTTVyKhnxqp/+m8DAOkaCY2 43sG7c898K8zn+G43oaYsEliwtvpg+P4fnkAoEiUqx5BgZ9x6ISVBEZBicoAQCPk0H8r DUDcNwOUbmUkYWavjrhf9jBWCM9uOv2pswrNF2bzpzJ+g83AY2GcZbl57oxt71J+h1jk gAUt97QPDVsv18kwENFVt23VNLI0umUyhF1C5qkb4IWNczrHytbnOvDdETBPkrQOYWY6 VrDWWPk6yN7wnHoRlYEy85WySxqh8vxZwD3AakRc/hpFn952UZ3bLASzTcsjcAhzQD9O xH9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc; bh=3+KFGw/lw7UFTEKp2QYuhuNuaZRNkMlHXcRjkBPuoco=; b=6+/32Qbl1ign1d2IBD5S/KZyk+WTCpjt/Fl75vhTe5ucKiT5Z09OJjo6EpS8CTuFLQ 8w7h4TIlmCp0ShBs6/clHM+MCSPXPuk0U3+cxCIyca5JnHWPS8i0PHWFKbeV5DnZ5xQq X2nPMF3OxdrFFG+kOuZQ/+a+5GVYSxDdiLpN4OvFQljWA5G4GZ3F103PZqTkJu8bWZXf jcFaIRI9EjtTIZ70e53OEhEsfRSfhC4OFyxW/Po4lYUD+YNef88fMrAcn6+ncrVUX7wP 4jh3EEU3WuceyZiZTEqxwb0kEn2HtveGQiJmlE7K6piIpw0x4K4kc6GyaL+/WtcUqI46 I+6w== X-Gm-Message-State: ACgBeo2elnkMffVgWTvvwN388kEQ58O7fYxbLMvJhuv1Y1OXO6fXUyG/ 29hQYuMXUXuKoXcuFv9kSkmCFYR+kfd7iA== X-Google-Smtp-Source: AA6agR7q6tV50augbDBj5FI+PYqaTZLRyKhIvbXKaLDo74MAo4aCJqE/LL9Fp9trQj2FgsIlB5oC5YO5eTaJOA== X-Received: from xllamas.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5070]) (user=cmllamas job=sendgmr) by 2002:a17:90b:3e8a:b0:1fb:27a0:c39b with SMTP id rj10-20020a17090b3e8a00b001fb27a0c39bmr20500444pjb.155.1661803979977; Mon, 29 Aug 2022 13:12:59 -0700 (PDT) Date: Mon, 29 Aug 2022 20:12:48 +0000 In-Reply-To: <20220829201254.1814484-1-cmllamas@google.com> Mime-Version: 1.0 References: <20220829201254.1814484-1-cmllamas@google.com> X-Mailer: git-send-email 2.37.2.672.g94769d06f0-goog Message-ID: <20220829201254.1814484-2-cmllamas@google.com> Subject: [PATCH 1/7] binder: fix alloc->vma_vm_mm null-ptr dereference From: Carlos Llamas To: Greg Kroah-Hartman , "=?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?=" , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Carlos Llamas , Suren Baghdasaryan , Andrew Morton , Liam Howlett Cc: kernel-team@android.com, syzbot+f7dc54e5be28950ac459@syzkaller.appspotmail.com, syzbot+a75ebe0452711c9e56d9@syzkaller.appspotmail.com, stable@vger.kernel.org, "Liam R . Howlett" , linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Syzbot reported a couple issues introduced by commit 44e602b4e52f ("binder_alloc: add missing mmap_lock calls when using the VMA"), in which we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not been initialized yet. This can happen if a binder_proc receives a transaction without having previously called mmap() to setup the binder_proc->alloc space in [1]. Also, a similar issue occurs via binder_alloc_print_pages() when we try to dump the debugfs binder stats file in [2]. Sample of syzbot's crash report: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-2022081= 9-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS G= oogle 07/22/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Call Trace: lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 down_read+0x98/0x450 kernel/locking/rwsem.c:1499 mmap_read_lock include/linux/mmap_lock.h:117 [inline] binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline] binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593 binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199 binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986 binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 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+0x63/0xcd [...] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fix these issues by setting up alloc->vma_vm_mm 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=3Df7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=3Da75ebe0452711c9e56d9 Fixes: 44e602b4e52f ("binder_alloc: add missing mmap_lock calls when using = the VMA") Reported-by: syzbot+f7dc54e5be28950ac459@syzkaller.appspotmail.com Reported-by: syzbot+a75ebe0452711c9e56d9@syzkaller.appspotmail.com Cc: # v5.15+ Cc: Liam R. Howlett Signed-off-by: Carlos Llamas Acked-by: Todd Kjos Reviewed-by: Liam R. Howlett --- drivers/android/binder_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 51f4e1c5cd01..9b1778c00610 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -322,7 +322,6 @@ static inline void binder_alloc_set_vma(struct binder_a= lloc *alloc, */ if (vma) { vm_start =3D vma->vm_start; - alloc->vma_vm_mm =3D vma->vm_mm; mmap_assert_write_locked(alloc->vma_vm_mm); } else { mmap_assert_locked(alloc->vma_vm_mm); @@ -795,7 +794,6 @@ int binder_alloc_mmap_handler(struct binder_alloc *allo= c, binder_insert_free_buffer(alloc, buffer); alloc->free_async_space =3D alloc->buffer_size / 2; binder_alloc_set_vma(alloc, vma); - mmgrab(alloc->vma_vm_mm); =20 return 0; =20 @@ -1091,6 +1089,8 @@ static struct shrinker binder_shrinker =3D { void binder_alloc_init(struct binder_alloc *alloc) { alloc->pid =3D current->group_leader->pid; + alloc->vma_vm_mm =3D current->mm; + mmgrab(alloc->vma_vm_mm); mutex_init(&alloc->mutex); INIT_LIST_HEAD(&alloc->buffers); } --=20 2.37.2.672.g94769d06f0-goog