linux-stable.git/drivers/staging/android, branch v4.19.321

staging: ion: Prevent incorrect reference counting behavour

2022-04-27T11:39:45+00:00

Supply additional check in order to prevent unexpected results.

Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Fix lockdep warning for write operation

2020-08-11T13:32:31+00:00

commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.

syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:

Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(fs_reclaim);
                                lock(&sb->s_type->i_mutex_key#13);
                                lock(fs_reclaim);
   lock(&sb->s_type->i_mutex_key#13);

kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.

[1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/

Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan 
Cc: stable 
Reviewed-by: Joel Fernandes (Google) 
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: use vmap instead of vm_map_ram

2020-06-22T07:05:12+00:00

[ Upstream commit 5bf9917452112694b2c774465ee4dbe441c84b77 ]

vm_map_ram can keep mappings around after the vm_unmap_ram.  Using that
with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Acked-by: Greg Kroah-Hartman 
Acked-by: Peter Zijlstra (Intel) 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Gao Xiang 
Cc: Haiyang Zhang 
Cc: Johannes Weiner 
Cc: "K. Y. Srinivasan" 
Cc: Laura Abbott 
Cc: Mark Rutland 
Cc: Michael Kelley 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Robin Murphy 
Cc: Sakari Ailus 
Cc: Stephen Hemminger 
Cc: Sumit Semwal 
Cc: Wei Liu 
Cc: Benjamin Herrenschmidt 
Cc: Catalin Marinas 
Cc: Heiko Carstens 
Cc: Paul Mackerras 
Cc: Vasily Gorbik 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

staging: android: ashmem: Disallow ashmem memory from being remapped

2020-02-28T15:38:45+00:00

commit 6d67b0290b4b84c477e6a2fc6e005e174d3c7786 upstream.

When ashmem file is mmapped, the resulting vma->vm_file points to the
backing shmem file with the generic fops that do not check ashmem
permissions like fops of ashmem do. If an mremap is done on the ashmem
region, then the permission checks will be skipped. Fix that by disallowing
mapping operation on the backing shmem file.

Reported-by: Jann Horn 
Signed-off-by: Suren Baghdasaryan 
Cc: stable  # 4.4,4.9,4.14,4.18,5.4
Signed-off-by: Todd Kjos 
Reviewed-by: Joel Fernandes (Google) 
Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman

staging: android: vsoc: fix copy_from_user overrun

2020-01-27T13:50:39+00:00

[ Upstream commit 060ea4271a82270be6d44e8e9aefe8f155fb5626 ]

The `np->permission' structure is smaller than the `np' structure but
sizeof(*np) worth of data is copied in there. Fix the size passed to
copy_from_user() to avoid overrun.

Fixes: 3d2ec9dcd553 ("staging: Android: Add 'vsoc' driver for cuttlefish.")
Signed-off-by: Vincent Stehlé 
Cc: Greg Kroah-Hartman 
Reviewed-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: android: ion: Bail out upon SIGKILL when allocating memory.

2019-08-16T08:12:38+00:00

commit 8f9e86ee795971eabbf372e6d804d6b8578287a7 upstream.

syzbot found that a thread can stall for minutes inside
ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
Let's check for SIGKILL before doing memory allocation.

[1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e

Signed-off-by: Tetsuo Handa 
Cc: stable 
Reported-by: syzbot 
Acked-by: Laura Abbott 
Acked-by: Sumit Semwal 
Link: https://lore.kernel.org/r/d088f188-5f32-d8fc-b9a0-0b404f7501cc@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman

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

2019-03-10T06:17:16+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 
Cc: stable@vger.kernel.org
Reviewed-by: Joel Fernandes 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Don't call fallocate() with ashmem_mutex held.

2019-03-10T06:17:16+00:00

commit fb4415a12632f0b9078a0aa80c16745d48fcfc74 upstream.

syzbot is hitting lockdep warnings [1][2][3]. This patch tries to fix
the warning by eliminating ashmem_shrink_scan() => {shmem|vfs}_fallocate()
sequence.

[1] https://syzkaller.appspot.com/bug?id=87c399f6fa6955006080b24142e2ce7680295ad4
[2] https://syzkaller.appspot.com/bug?id=7ebea492de7521048355fc84210220e1038a7908
[3] https://syzkaller.appspot.com/bug?id=e02419c12131c24e2a957ea050c2ab6dcbbc3270

Reported-by: syzbot 
Reported-by: syzbot 
Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Acked-by: Joel Fernandes (Google) 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: fix sys heap pool's gfp_flags

2019-03-10T06:17:16+00:00

commit 9bcf065e28122588a6cbee08cf847826dacbb438 upstream.

In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.

Fixes: e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up cached buffer alloc")
Signed-off-by: Qing Xia 
Cc: stable 
Signed-off-by: Jing Xia 
Reviewed-by: Yuming Han 
Reviewed-by: Zhaoyang Huang 
Reviewed-by: Orson Zhai 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: Support cpu access during dma_buf_detach

2019-03-05T16:58:50+00:00

[ Upstream commit 31eb79db420a3f94c4c45a8c0a05cd30e333f981 ]

Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.

Thread A				Thread B
- DMA_BUF_IOCTL_SYNC IOCT
 - ion_dma_buf_begin_cpu_access
  - list_for_each_entry
					- ion_dma_buf_detatch
					 - free_duped_table
   - dma_sync_sg_for_cpu

Fix this by getting the ion_buffer lock before freeing the sg table memory.

Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and mapping")
Signed-off-by: Liam Mark 
Acked-by: Laura Abbott 
Acked-by: Andrew F. Davis 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin