linux-toradex.git/drivers/android/binder_alloc.c, branch v6.7-rc1

binder: dynamically allocate the android-binder shrinker

2023-10-04T17:32:23+00:00

Use new APIs to dynamically allocate the android-binder shrinker.

Link: https://lkml.kernel.org/r/20230911094444.68966-4-zhengqi.arch@bytedance.com
Signed-off-by: Qi Zheng 
Reviewed-by: Muchun Song 
Acked-by: Carlos Llamas 
Cc: Greg Kroah-Hartman 
Cc: Abhinav Kumar 
Cc: Alasdair Kergon 
Cc: Alexander Viro 
Cc: Alyssa Rosenzweig 
Cc: Andreas Dilger 
Cc: Andreas Gruenbacher 
Cc: Anna Schumaker 
Cc: Arnd Bergmann 
Cc: Bob Peterson 
Cc: Borislav Petkov 
Cc: Chandan Babu R 
Cc: Chao Yu 
Cc: Chris Mason 
Cc: Christian Brauner 
Cc: Christian Koenig 
Cc: Chuck Lever 
Cc: Coly Li 
Cc: Dai Ngo 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: "Darrick J. Wong" 
Cc: Dave Chinner 
Cc: Dave Hansen 
Cc: David Airlie 
Cc: David Hildenbrand 
Cc: David Sterba 
Cc: Dmitry Baryshkov 
Cc: Gao Xiang 
Cc: Huang Rui 
Cc: Ingo Molnar 
Cc: Jaegeuk Kim 
Cc: Jani Nikula 
Cc: Jan Kara 
Cc: Jason Wang 
Cc: Jeff Layton 
Cc: Jeffle Xu 
Cc: Joel Fernandes (Google) 
Cc: Joonas Lahtinen 
Cc: Josef Bacik 
Cc: Juergen Gross 
Cc: Kent Overstreet 
Cc: Kirill Tkhai 
Cc: Marijn Suijten 
Cc: "Michael S. Tsirkin" 
Cc: Mike Snitzer 
Cc: Minchan Kim 
Cc: Muchun Song 
Cc: Nadav Amit 
Cc: Neil Brown 
Cc: Oleksandr Tyshchenko 
Cc: Olga Kornievskaia 
Cc: Paul E. McKenney 
Cc: Richard Weinberger 
Cc: Rob Clark 
Cc: Rob Herring 
Cc: Rodrigo Vivi 
Cc: Roman Gushchin 
Cc: Sean Paul 
Cc: Sergey Senozhatsky 
Cc: Song Liu 
Cc: Stefano Stabellini 
Cc: Steven Price 
Cc: "Theodore Ts'o" 
Cc: Thomas Gleixner 
Cc: Tomeu Vizoso 
Cc: Tom Talpey 
Cc: Trond Myklebust 
Cc: Tvrtko Ursulin 
Cc: Vlastimil Babka 
Cc: Xuan Zhuo 
Cc: Yue Hu 
Signed-off-by: Andrew Morton

binder: fix memory leak in binder_init()

2023-08-04T13:25:01+00:00

In binder_init(), the destruction of binder_alloc_shrinker_init() is not
performed in the wrong path, which will cause memory leaks. So this commit
introduces binder_alloc_shrinker_exit() and calls it in the wrong path to
fix that.

Signed-off-by: Qi Zheng 
Acked-by: Carlos Llamas 
Fixes: f2517eb76f1f ("android: binder: Add global lru shrinker to binder")
Cc: stable 
Link: https://lore.kernel.org/r/20230625154937.64316-1-qi.zheng@linux.dev
Signed-off-by: Greg Kroah-Hartman

binder: fix UAF of alloc->vma in race with munmap()

2023-05-20T16:56:23+00:00

[ cmllamas: clean forward port from commit 015ac18be7de ("binder: fix
  UAF of alloc->vma in race with munmap()") in 5.10 stable. It is needed
  in mainline after the revert of commit a43cfc87caaf ("android: binder:
  stop saving a pointer to the VMA") as pointed out by Liam. The commit
  log and tags have been tweaked to reflect this. ]

In commit 720c24192404 ("ANDROID: binder: change down_write to
down_read") binder assumed the mmap read lock is sufficient to protect
alloc->vma inside binder_update_page_range(). This used to be accurate
until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap"), which now downgrades the mmap_lock after detaching the vma
from the rbtree in munmap(). Then it proceeds to teardown and free the
vma with only the read lock held.

This means that accesses to alloc->vma in binder_update_page_range() now
will race with vm_area_free() in munmap() and can cause a UAF as shown
in the following KASAN trace:

  ==================================================================
  BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0
  Read of size 8 at addr ffff16204ad00600 by task server/558

  CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   dump_backtrace+0x0/0x2a0
   show_stack+0x18/0x2c
   dump_stack+0xf8/0x164
   print_address_description.constprop.0+0x9c/0x538
   kasan_report+0x120/0x200
   __asan_load8+0xa0/0xc4
   vm_insert_page+0x7c/0x1f0
   binder_update_page_range+0x278/0x50c
   binder_alloc_new_buf+0x3f0/0xba0
   binder_transaction+0x64c/0x3040
   binder_thread_write+0x924/0x2020
   binder_ioctl+0x1610/0x2e5c
   __arm64_sys_ioctl+0xd4/0x120
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  Allocated by task 559:
   kasan_save_stack+0x38/0x6c
   __kasan_kmalloc.constprop.0+0xe4/0xf0
   kasan_slab_alloc+0x18/0x2c
   kmem_cache_alloc+0x1b0/0x2d0
   vm_area_alloc+0x28/0x94
   mmap_region+0x378/0x920
   do_mmap+0x3f0/0x600
   vm_mmap_pgoff+0x150/0x17c
   ksys_mmap_pgoff+0x284/0x2dc
   __arm64_sys_mmap+0x84/0xa4
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  Freed by task 560:
   kasan_save_stack+0x38/0x6c
   kasan_set_track+0x28/0x40
   kasan_set_free_info+0x24/0x4c
   __kasan_slab_free+0x100/0x164
   kasan_slab_free+0x14/0x20
   kmem_cache_free+0xc4/0x34c
   vm_area_free+0x1c/0x2c
   remove_vma+0x7c/0x94
   __do_munmap+0x358/0x710
   __vm_munmap+0xbc/0x130
   __arm64_sys_munmap+0x4c/0x64
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  [...]
  ==================================================================

To prevent the race above, revert back to taking the mmap write lock
inside binder_update_page_range(). One might expect an increase of mmap
lock contention. However, binder already serializes these calls via top
level alloc->mutex. Also, there was no performance impact shown when
running the binder benchmark tests.

Fixes: c0fd2101781e ("Revert "android: binder: stop saving a pointer to the VMA"")
Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
Reported-by: Jann Horn 
Closes: https://lore.kernel.org/all/20230518144052.xkj6vmddccq4v66b@revolver
Cc: 
Cc: Minchan Kim 
Cc: Yang Shi 
Cc: Liam Howlett 
Signed-off-by: Carlos Llamas 
Acked-by: Todd Kjos 
Link: https://lore.kernel.org/r/20230519195950.1775656-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

binder: add lockless binder_alloc_(set|get)_vma()

2023-05-13T11:30:16+00:00

Bring back the original lockless design in binder_alloc to determine
whether the buffer setup has been completed by the ->mmap() handler.
However, this time use smp_load_acquire() and smp_store_release() to
wrap all the ordering in a single macro call.

Also, add comments to make it evident that binder uses alloc->vma to
determine when the binder_alloc has been fully initialized. In these
scenarios acquiring the mmap_lock is not required.

Fixes: a43cfc87caaf ("android: binder: stop saving a pointer to the VMA")
Cc: Liam Howlett 
Cc: Suren Baghdasaryan 
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas 
Link: https://lore.kernel.org/r/20230502201220.1756319-3-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

Revert "android: binder: stop saving a pointer to the VMA"

2023-05-13T11:30:16+00:00

This reverts commit a43cfc87caaf46710c8027a8c23b8a55f1078f19.

This patch fixed an issue reported by syzkaller in [1]. However, this
turned out to be only a band-aid in binder. The root cause, as bisected
by syzkaller, was fixed by commit 5789151e48ac ("mm/mmap: undo ->mmap()
when mas_preallocate() fails"). We no longer need the patch for binder.

Reverting such patch allows us to have a lockless access to alloc->vma
in specific cases where the mmap_lock is not required. This approach
avoids the contention that caused a performance regression.

[1] https://lore.kernel.org/all/0000000000004a0dbe05e1d749e0@google.com

[cmllamas: resolved conflicts with rework of alloc->mm and removal of
 binder_alloc_set_vma() also fixed comment section]

Fixes: a43cfc87caaf ("android: binder: stop saving a pointer to the VMA")
Cc: Liam Howlett 
Cc: Suren Baghdasaryan 
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas 
Link: https://lore.kernel.org/r/20230502201220.1756319-2-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

Revert "binder_alloc: add missing mmap_lock calls when using the VMA"

2023-05-13T11:30:16+00:00

This reverts commit 44e602b4e52f70f04620bbbf4fe46ecb40170bde.

This caused a performance regression particularly when pages are getting
reclaimed. We don't need to acquire the mmap_lock to determine when the
binder buffer has been fully initialized. A subsequent patch will bring
back the lockless approach for this.

[cmllamas: resolved trivial conflicts with renaming of alloc->mm]

Fixes: 44e602b4e52f ("binder_alloc: add missing mmap_lock calls when using the VMA")
Cc: Liam Howlett 
Cc: Suren Baghdasaryan 
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas 
Link: https://lore.kernel.org/r/20230502201220.1756319-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

mm: remove zap_page_range and create zap_vma_pages

2023-01-19T01:12:55+00:00

zap_page_range was originally designed to unmap pages within an address
range that could span multiple vmas.  While working on [1], it was
discovered that all callers of zap_page_range pass a range entirely within
a single vma.  In addition, the mmu notification call within zap_page
range does not correctly handle ranges that span multiple vmas.  When
crossing a vma boundary, a new mmu_notifier_range_init/end call pair with
the new vma should be made.

Instead of fixing zap_page_range, do the following:
- Create a new routine zap_vma_pages() that will remove all pages within
  the passed vma.  Most users of zap_page_range pass the entire vma and
  can use this new routine.
- For callers of zap_page_range not passing the entire vma, instead call
  zap_page_range_single().
- Remove zap_page_range.

[1] https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.kravetz@oracle.com/
Link: https://lkml.kernel.org/r/20230104002732.232573-1-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz 
Suggested-by: Peter Xu 
Acked-by: Michal Hocko 
Acked-by: Peter Xu 
Acked-by: Heiko Carstens 	[s390]
Reviewed-by: Christoph Hellwig 
Cc: Christian Borntraeger 
Cc: Christian Brauner 
Cc: Dave Hansen 
Cc: David Hildenbrand 
Cc: Eric Dumazet 
Cc: Matthew Wilcox 
Cc: Michael Ellerman 
Cc: Nadav Amit 
Cc: Palmer Dabbelt 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

binder: validate alloc->mm in ->mmap() handler

2022-11-09T14:41:27+00:00

Since commit 1da52815d5f1 ("binder: fix alloc->vma_vm_mm null-ptr
dereference") binder caches a pointer to the current->mm during open().
This fixes a null-ptr dereference reported by syzkaller. Unfortunately,
it also opens the door for a process to update its mm after the open(),
(e.g. via execve) making the cached alloc->mm pointer invalid.

Things get worse when the process continues to mmap() a vma. From this
point forward, binder will attempt to find this vma using an obsolete
alloc->mm reference. Such as in binder_update_page_range(), where the
wrong vma is obtained via vma_lookup(), yet binder proceeds to happily
insert new pages into it.

To avoid this issue fail the ->mmap() callback if we detect a mismatch
between the vma->vm_mm and the original alloc->mm pointer. This prevents
alloc->vm_addr from getting set, so that any subsequent vma_lookup()
calls fail as expected.

Fixes: 1da52815d5f1 ("binder: fix alloc->vma_vm_mm null-ptr dereference")
Reported-by: Jann Horn 
Cc:  # 5.15+
Signed-off-by: Carlos Llamas 
Acked-by: Todd Kjos 
Link: https://lore.kernel.org/r/20221104231235.348958-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

binder: remove binder_alloc_set_vma()

2022-09-06T15:02:06+00:00

The mmap_locked asserts here are not needed since this is only called
back from the mmap stack in ->mmap() and ->close() which always acquire
the lock first. Remove these asserts along with binder_alloc_set_vma()
altogether since it's trivial enough to be consumed by callers.

Cc: Liam R. Howlett 
Signed-off-by: Carlos Llamas 
Link: https://lore.kernel.org/r/20220906135948.3048225-3-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman

binder: rename alloc->vma_vm_mm to alloc->mm

2022-09-06T15:02:06+00:00

Rename ->vma_vm_mm to ->mm to reflect the fact that we no longer cache
this reference from vma->vm_mm but from current->mm instead.

No functional changes in this patch.

Reviewed-by: Christian Brauner (Microsoft) 
Acked-by: Todd Kjos 
Signed-off-by: Carlos Llamas 
Link: https://lore.kernel.org/r/20220906135948.3048225-2-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman