linux-stable.git/drivers/staging/android, branch v3.16.82

binder: Handle start==NULL in binder_update_page_range()

2020-02-11T20:03:40+00:00

commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream.

The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
continuing backwards to index -1 and crashing.

Luckily you need to be highly privileged to map things at NULL, so it's not
a big problem.

Fix it by adjusting the loop so that the loop variable is always in bounds.

This patch is deliberately minimal to simplify backporting, but IMO this
function could use a refactor. The jump labels in the second loop body are
horrible (the error gotos should be jumping to free_range instead), and
both loops would look nicer if they just iterated upwards through indices.
And the up_read()+mmput() shouldn't be duplicated like that.

Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Signed-off-by: Jann Horn 
Acked-by: Christian Brauner 
Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: There is no continue statement in the loop,
 so we only need to check the exit condition at the bottom]
Signed-off-by: Ben Hutchings

staging: ion: Set minimum carveout heap allocation order to PAGE_SHIFT

2020-01-11T02:04:52+00:00

commit 1328d8efef17d5e16bd6e9cfe59130a833674534 upstream.

In carveout heap, change minimum allocation order from 12 to
PAGE_SHIFT. After this change each bit in bitmap (genalloc -
General purpose special memory pool) represents one page size
memory.

Cc: sprd-ind-kernel-group@googlegroups.com
Cc: sanjeev.yadav@spreadtrum.com
Cc: Colin Cross 
Cc: Android Kernel Team 
Cc: Greg KH 
Cc: Sumit Semwal 
Signed-off-by: Rajmal Menariya 
[jstultz: Reworked commit message]
Signed-off-by: John Stultz 
Acked-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

staging: ashmem: Add missing include

2020-01-11T02:04:52+00:00

commit 90a2f171383b5ae43b33ab4d9d566b9765622ac7 upstream.

Include  into ashmem.h to ensure referenced types
are defined

Cc: Android Kernel Team 
Cc: Greg KH 
Signed-off-by: Rom Lemarchand 
[jstultz: Minor commit message tweaks]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

staging: ashmem: Avoid deadlock with mmap/shrink

2020-01-11T02:04:51+00:00

commit 18e77054de741ef3ed2a2489bc9bf82a318b2d5e upstream.

Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may
be possible for ashmem_mmap to invoke ashmem_shrink:

-000|mutex_lock(lock = 0x0)
-001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again
-002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages
-002|=
-002|124)
-003|try_to_free_pages(zonelist = 0x0, ?, ?, ?)
-004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist =
-004|0xC11D0940,
-005|new_slab(s = 0xE4841E80, ?, node = -1)
-006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags =
-006|2148925462, ad
-007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208)
-008|shmem_alloc_inode(?)
-009|alloc_inode(sb = 0xE480E800)
-010|new_inode_pseudo(?)
-011|new_inode(?)
-012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags =
-012|187)
-013|shmem_file_setup(?, ?, flags = 187)
-014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex
-015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472,
-015|flags = 57,
-016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd =
-016|157, pgoff
-017|ret_fast_syscall(asm)
-->|exception
-018|NUR:0x40097508(asm)
---|end of frame

Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex
is already held, do not attempt to shrink.

Cc: Greg KH 
Cc: Android Kernel Team 
Reported-by: Matt Wagantall 
Reported-by: Syed Rameez Mustafa 
Reported-by: Osvaldo Banuelos 
Reported-by: Subbaraman Narayanamurthy 
Signed-off-by: Laura Abbott 
[jstultz: Minor commit message tweaks]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

ANDROID: binder: remove waitqueue when thread exits.

2019-12-10T18:01:28+00:00

commit f5cb779ba16334b45ba8946d6bfa6d9834d1527f upstream.

binder_poll() passes the thread->wait waitqueue that
can be slept on for work. When a thread that uses
epoll explicitly exits using BINDER_THREAD_EXIT,
the waitqueue is freed, but it is never removed
from the corresponding epoll data structure. When
the process subsequently exits, the epoll cleanup
code tries to access the waitlist, which results in
a use-after-free.

Prevent this by using POLLFREE when the thread exits.

Signed-off-by: Martijn Coenen 
Reported-by: syzbot 
[backport BINDER_LOOPER_STATE_POLL logic as well]
Signed-off-by: Mattias Nissler 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

binder: Replace "%p" with "%pK" for stable

2019-07-09T21:04:20+00:00

This was done as part of upstream commits fdfb4a99b6ab "8inder:
separate binder allocator structure from binder proc", 19c987241ca1
"binder: separate out binder_alloc functions", and 7a4408c6bd3e
"binder: make sure accesses to proc/thread are safe".  However, those
commits made lots of other changes that are not suitable for stable.

Signed-off-by: Ben Hutchings 
Signed-off-by: Ben Hutchings

staging: android: ashmem: Avoid range_alloc() allocation with ashmem_mutex held.

2019-07-09T21:04:07+00:00

commit ecd182cbf4e107928077866399100228d2359c60 upstream.

ashmem_pin() is calling range_shrink() without checking whether
range_alloc() succeeded. Also, doing memory allocation with ashmem_mutex
held should be avoided because ashmem_shrink_scan() tries to hold it.

Therefore, move memory allocation for range_alloc() to ashmem_pin_unpin()
and make range_alloc() not to fail.

This patch is mostly meant for backporting purpose for fuzz testing on
stable/distributor kernels, for there is a plan to remove this code in
near future.

Signed-off-by: Tetsuo Handa 
Reviewed-by: Joel Fernandes 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

staging: android: ion: Return an ERR_PTR in ion_map_kernel

2018-11-20T18:05:27+00:00

commit 0a2bc00341dcfcc793c0dbf4f8d43adf60458b05 upstream.

The expected return value from ion_map_kernel is an ERR_PTR. The error
path for a vmalloc failure currently just returns NULL, triggering
a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR.

Reported-by: syzbot+55b1d9f811650de944c6@syzkaller.appspotmail.com
Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

staging: android: ion: Switch to pr_warn_once in ion_buffer_destroy

2018-11-20T18:04:55+00:00

commit 45ad559a29629cb1c64ee636563c69b71524f077 upstream.

Syzbot reported yet another warning with Ion:

WARNING: CPU: 0 PID: 1467 at drivers/staging/android/ion/ion.c:122
ion_buffer_destroy+0xd4/0x190 drivers/staging/android/ion/ion.c:122
Kernel panic - not syncing: panic_on_warn set ...

This is catching that a buffer was freed with an existing kernel mapping
still present. This can be easily be triggered from userspace by calling
DMA_BUF_SYNC_START without calling DMA_BUF_SYNC_END. Switch to a single
pr_warn_once to indicate the error without being disruptive.

Reported-by: syzbot+cd8bcd40cb049efa2770@syzkaller.appspotmail.com
Reported-by: syzbot 
Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

staging: android: ashmem: Fix lockdep issue during llseek

2018-06-16T21:22:31+00:00

commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.

ashmem_mutex create a chain of dependencies like so:

(1)
mmap syscall ->
  mmap_sem ->  (acquired)
  ashmem_mmap
  ashmem_mutex (try to acquire)
  (block)

(2)
llseek syscall ->
  ashmem_llseek ->
  ashmem_mutex ->  (acquired)
  inode_lock ->
  inode->i_rwsem (try to acquire)
  (block)

(3)
getdents ->
  iterate_dir ->
  inode_lock ->
  inode->i_rwsem   (acquired)
  copy_to_user ->
  mmap_sem         (try to acquire)

There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.

[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48

Acked-by: Todd Kjos 
Cc: Arve Hjonnevag 
Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes 
Acked-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings