linux-stable.git/drivers/android/binder_alloc.c, branch v5.19.2

android: binder: stop saving a pointer to the VMA

2022-08-17T13:15:40+00:00

[ Upstream commit a43cfc87caaf46710c8027a8c23b8a55f1078f19 ]

Do not record a pointer to a VMA outside of the mmap_lock for later use.
This is unsafe and there are a number of failure paths *after* the
recorded VMA pointer may be freed during setup.  There is no callback to
the driver to clear the saved pointer from generic mm code.  Furthermore,
the VMA pointer may become stale if any number of VMA operations end up
freeing the VMA so saving it was fragile to being with.

Instead, change the binder_alloc struct to record the start address of the
VMA and use vma_lookup() to get the vma when needed.  Add lockdep
mmap_lock checks on updates to the vma pointer to ensure the lock is held
and depend on that lock for synchronization of readers and writers - which
was already the case anyways, so the smp_wmb()/smp_rmb() was not
necessary.

[akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]
Link: https://lkml.kernel.org/r/20220621140212.vpkio64idahetbyf@revolver
Fixes: da1b9564e85b ("android: binder: fix the race mmap and alloc_new_buf_locked")
Reported-by: syzbot+58b51ac2b04e388ab7b0@syzkaller.appspotmail.com
Signed-off-by: Liam R. Howlett 
Cc: Minchan Kim 
Cc: Christian Brauner (Microsoft) 
Cc: Greg Kroah-Hartman 
Cc: Hridya Valsaraju 
Cc: Joel Fernandes 
Cc: Martijn Coenen 
Cc: Suren Baghdasaryan 
Cc: Todd Kjos 
Cc: Matthew Wilcox (Oracle) 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

binder: Use memcpy_{to,from}_page() in binder_alloc_do_buffer_copy()

2022-04-26T10:51:31+00:00

The use of kmap_atomic() is being deprecated in favor of kmap_local_page()
where it is feasible. Each call of kmap_atomic() in the kernel creates
a non-preemptible section and disable pagefaults. This could be a source
of unwanted latency, so kmap_local_page() should be preferred.

With kmap_local_page(), the mapping is per thread, CPU local and not
globally visible. Furthermore, the mapping can be acquired from any context
(including interrupts). binder_alloc_do_buffer_copy() is a function where
the use of kmap_local_page() in place of kmap_atomic() is correctly suited.

Use kmap_local_page() / kunmap_local() in place of kmap_atomic() /
kunmap_atomic() but, instead of open coding the mappings and call memcpy()
to and from the virtual addresses of the mapped pages, prefer the use of
the memcpy_{to,from}_page() wrappers (as suggested by Christophe
Jaillet).

Cc: Christophe JAILLET 
Acked-by: Todd Kjos 
Signed-off-by: Fabio M. De Francesco 
Link: https://lore.kernel.org/r/20220425175754.8180-4-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman

binder: Use kmap_local_page() in binder_alloc_copy_user_to_buffer()

2022-04-26T10:51:31+00:00

The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible. With kmap_local_page(), the mapping is per
thread, CPU local and not globally visible.

binder_alloc_copy_user_to_buffer() is a function where the use of
kmap_local_page() in place of kmap() is correctly suited because
the mapping is local to the thread.

Therefore, use kmap_local_page() / kunmap_local().

Cc: Christophe JAILLET 
Acked-by: Todd Kjos 
Signed-off-by: Fabio M. De Francesco 
Link: https://lore.kernel.org/r/20220425175754.8180-3-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman

binder: Use memset_page() in binder_alloc_clear_buf()

2022-04-26T10:51:31+00:00

The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible. With kmap_local_page(), the mapping is per
thread, CPU local and not globally visible.

binder_alloc_clear_buf() is a function where the use of kmap_local_page()
in place of kmap() is correctly suited because the mapping is local to the
thread.

Therefore, use kmap_local_page() / kunmap_local() but, instead of open
coding these two functions and adding a memset() of the virtual address
of the mapping, prefer memset_page().

Cc: Christophe JAILLET 
Acked-by: Todd Kjos 
Signed-off-by: Fabio M. De Francesco 
Link: https://lore.kernel.org/r/20220425175754.8180-2-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman

drivers/android: remove redundant ret variable

2022-02-04T14:40:44+00:00

Return value from list_lru_count() directly instead
of taking this in another redundant variable.

Reported-by: Zeal Robot 
Signed-off-by: Minghao Chi 
Signed-off-by: CGEL ZTE 
Link: https://lore.kernel.org/r/20220104113500.602158-1-chi.minghao@zte.com.cn
Signed-off-by: Greg Kroah-Hartman

binder: fix async_free_space accounting for empty parcels

2021-12-21T10:07:34+00:00

In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
fixed a kernel structure visibility issue. As part of that patch,
sizeof(void *) was used as the buffer size for 0-length data payloads so
the driver could detect abusive clients sending 0-length asynchronous
transactions to a server by enforcing limits on async_free_size.

Unfortunately, on the "free" side, the accounting of async_free_space
did not add the sizeof(void *) back. The result was that up to 8-bytes of
async_free_space were leaked on every async transaction of 8-bytes or
less.  These small transactions are uncommon, so this accounting issue
has gone undetected for several years.

The fix is to use "buffer_size" (the allocated buffer size) instead of
"size" (the logical buffer size) when updating the async_free_space
during the free operation. These are the same except for this
corner case of asynchronous transactions with payloads < 8 bytes.

Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
Signed-off-by: Todd Kjos 
Cc: stable@vger.kernel.org # 4.14+
Link: https://lore.kernel.org/r/20211220190150.2107077-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman

binder: tell userspace to dump current backtrace when detected oneway spamming

2021-04-10T08:52:04+00:00

When async binder buffer got exhausted, some normal oneway transactions
will also be discarded and may cause system or application failures. By
that time, the binder debug information we dump may not be relevant to
the root cause. And this issue is difficult to debug if without the
backtrace of the thread sending spam.

This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when oneway
spamming is detected, request to dump current backtrace. Oneway spamming
will be reported only once when exceeding the threshold (target process
dips below 80% of its oneway space, and current process is responsible for
either more than 50 transactions, or more than 50% of the oneway space).
And the detection will restart when the async buffer has returned to a
healthy state.

Acked-by: Todd Kjos 
Signed-off-by: Hang Lu 
Link: https://lore.kernel.org/r/1617961246-4502-3-git-send-email-hangl@codeaurora.org
Signed-off-by: Greg Kroah-Hartman

binder: add flag to clear buffer on txn complete

2020-12-09T14:41:21+00:00

Add a per-transaction flag to indicate that the buffer
must be cleared when the transaction is complete to
prevent copies of sensitive data from being preserved
in memory.

Signed-off-by: Todd Kjos 
Link: https://lore.kernel.org/r/20201120233743.3617529-1-tkjos@google.com
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

binder: remove redundant assignment to pointer n

2020-09-16T15:30:37+00:00

The pointer n is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.

Acked-by: Todd Kjos 
Acked-by: Christian Brauner 
Signed-off-by: Colin Ian King 
Link: https://lore.kernel.org/r/20200910151221.751464-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman

binder: print warnings when detecting oneway spamming.

2020-09-03T16:24:41+00:00

The most common cause of the binder transaction buffer filling up is a
client rapidly firing oneway transactions into a process, before it has
a chance to handle them. Yet the root cause of this is often hard to
debug, because either the system or the app will stop, and by that time
binder debug information we dump in bugreports is no longer relevant.

This change warns as soon as a process dips below 80% of its oneway
space (less than 100kB available in the configuration), when any one
process is responsible for either more than 50 transactions, or more
than 50% of the oneway space.

Signed-off-by: Martijn Coenen 
Acked-by: Todd Kjos 
Link: https://lore.kernel.org/r/20200821122544.1277051-1-maco@android.com
Signed-off-by: Greg Kroah-Hartman