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

staging: ion: Prevent incorrect reference counting behavour

2021-12-08T07:45:02+00:00

Supply additional checks 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: ion: fix page is NULL

2021-09-26T11:36:17+00:00

Fixes: commit e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up cached buffer alloc")
the commit e7f63771b60e introduced the bug which didn't test page which maybe NULL.
and previous logic was right.

the e7f63771b60e has been merged in v4.8-rc3, only longterm 4.9.x has this bug,
and other longterm/stable version have not.

kernel panic is here when page is NULL:

Unable to handle kernel paging request at virtual address b0380000
pgd = d9d94000
[b0380000] *pgd=00000000
Internal error: Oops: 2805 [#1] PREEMPT SMP ARM
...
task: daa2dd00 task.stack: da194000
PC is at v7_dma_clean_range+0x1c/0x34
LR is at arm_dma_sync_single_for_device+0x44/0x58
pc : []    lr : []    psr: 200f0013
sp : da195da0  ip : dc1f9000  fp : c1043dc4
r10: 00000000  r9 : c16f1f58  r8 : 00000001
r7 : c1621f94  r6 : c0116418  r5 : 00000000  r4 : c011aa58
r3 : 0000003f  r2 : 00000040  r1 : b0480000  r0 : b0380000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5383d  Table: 19d9406a  DAC: 00000051
...
[] (v7_dma_clean_range) from [] (arm_dma_sync_single_for_device+0x44/0x58)
[] (arm_dma_sync_single_for_device) from [] (arm_dma_sync_sg_for_device+0x50/0x7c)
[] (arm_dma_sync_sg_for_device) from [] (ion_pages_sync_for_device+0xb0/0xec)
[] (ion_pages_sync_for_device) from [] (ion_system_heap_allocate+0x2a0/0x2e0)
[] (ion_system_heap_allocate) from [] (ion_alloc+0x12c/0x494)
[] (ion_alloc) from [] (ion_ioctl+0x510/0x63c)
[] (ion_ioctl) from [] (do_vfs_ioctl+0xa8/0x9b4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x48)
Code: e3a02004 e1a02312 e2423001 e1c00003 (ee070f3a)
---[ end trace 89278304932c0e87 ]---
Kernel panic - not syncing: Fatal exception

Signed-off-by: Cheng Chao 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: use vmap instead of vm_map_ram

2020-06-20T08:24:15+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-28T14:42: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: ion: fix sys heap pool's gfp_flags

2019-03-13T21:04:52+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: ashmem: Fix mmap size validation

2018-10-04T00:01:46+00:00

[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]

The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.

Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.

Cc: Todd Kjos 
Cc: devel@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com
Cc: Joel Fernandes 
Signed-off-by: Alistair Strachan 
Acked-by: Joel Fernandes (Google) 
Reviewed-by: Martijn Coenen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: check for kref overflow

2018-09-05T07:20:11+00:00

This patch is against 4.9. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface")

Userspace can cause the kref to handles to increment
arbitrarily high. Ensure it does not overflow.

Signed-off-by: Daniel Rosenberg 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

2018-09-05T07:20:06+00:00

This patch is 4.9.y only.  Kernels 4.12 and later are unaffected, since
all the underlying ion_handle infrastructure has been ripped out.

The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles.  This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:

- thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
- thread A: starts ION_IOC_MAP and increments the refcount to 2
- thread B: ION_IOC_FREE decrements the refcount to 1
- thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
            handle
- thread A: continues ION_IOC_MAP with a dangling ion_handle * to
            freed memory

Fix this by holding client->lock for the duration of
ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
remove ion_handle_get_by_id(), since there's literally no way to use it
safely.

Cc: stable@vger.kernel.org # v4.11-
Signed-off-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: Return an ERR_PTR in ion_map_kernel

2018-07-11T14:26:42+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 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: Switch to pr_warn_once in ion_buffer_destroy

2018-06-16T07:52:33+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 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman