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

ion: Make user_ion_handle_put_nolock() a void function

2022-08-25T09:09:21+00:00

Clang warns:

  drivers/staging/android/ion/ion-ioctl.c:71:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
          if (--handle->user_ref_count == 0)
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/staging/android/ion/ion-ioctl.c:74:9: note: uninitialized use occurs here
          return ret;
                 ^~~
  drivers/staging/android/ion/ion-ioctl.c:71:2: note: remove the 'if' if its condition is always true
          if (--handle->user_ref_count == 0)
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/staging/android/ion/ion-ioctl.c:69:9: note: initialize the variable 'ret' to silence this warning
          int ret;
                 ^
                  = 0
  1 warning generated.

The return value of user_ion_handle_put_nolock() is not checked in its
one call site in user_ion_free_nolock() so just make
user_ion_handle_put_nolock() return void to remove the warning.

Fixes: a8200613c8c9 ("ion: Protect kref from userspace manipulation")
Reported-by: kernel test robot 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

ion: Do not 'put' ION handle until after its final use

2022-01-29T09:15:58+00:00

pass_to_user() eventually calls kref_put() on an ION handle which is
still live, potentially allowing for it to be legitimately freed by
the client.

Prevent this from happening before its final use in both ION_IOC_ALLOC
and ION_IOC_IMPORT.

Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

ion: Protect kref from userspace manipulation

2022-01-29T09:15:58+00:00

This separates the kref for ion handles into two components.
Userspace requests through the ioctl will hold at most one
reference to the internally used kref. All additional requests
will increment a separate counter, and the original reference is
only put once that counter hits 0. This protects the kernel from
a poorly behaving userspace.

Signed-off-by: Daniel Rosenberg 
[d-cagle@codeaurora.org: Resolve style issues]
Signed-off-by: Dennis Cagle 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

ion: Fix use after free during ION_IOC_ALLOC

2022-01-29T09:15:58+00:00

If a user happens to call ION_IOC_FREE during an ION_IOC_ALLOC
on the just allocated id, and the copy_to_user fails, the cleanup
code will attempt to free an already freed handle.

This adds a wrapper for ion_alloc that adds an ion_handle_get to
avoid this.

Signed-off-by: Daniel Rosenberg 
Signed-off-by: Dennis Cagle 
Signed-off-by: Patrick Daly 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

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: 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: 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