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

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

2018-09-15T07:40:37+00:00

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.

This patch is applied on top of 4.4.y, and applies to older kernels
too.  4.9.y was fixed separately.  Kernels 4.12 and later are
unaffected, since all the underlying ion_handle infrastructure has been
ripped out.

Cc: stable@vger.kernel.org # v4.4-
Signed-off-by: Greg Hackmann 
Acked-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: check for kref overflow

2018-08-24T11:27:00+00:00

This patch is against 4.4. 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: Return an ERR_PTR in ion_map_kernel

2018-07-11T14:03:47+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: ion : Donnot wakeup kswapd in ion system alloc

2018-04-29T05:50:01+00:00

commit 2ef230531ee171a475fc3ddad5516dd7e09a8a77 upstream.

Since ion alloc can be called by userspace,eg gralloc.
When it is called frequently, the efficiency of kswapd is
to low. And the reclaimed memory is too lower. In this way,
the kswapd can use to much cpu resources.

With 3.5GB DMA Zone and 0.5 Normal Zone.

pgsteal_kswapd_dma 9364140
pgsteal_kswapd_normal 7071043
pgscan_kswapd_dma 10428250
pgscan_kswapd_normal 37840094

With this change the reclaim ratio has greatly improved
18.9% -> 72.5%

Signed-off-by: Chen Feng 
Signed-off-by: Lu bing 
Reviewed-by: Laura Abbott 
Cc: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

staging/android/ion : fix a race condition in the ion driver

2017-04-30T03:49:29+00:00

commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 upstream.

There is a use-after-free problem in the ion driver.
This is caused by a race condition in the ion_ioctl()
function.

A handle has ref count of 1 and two tasks on different
cpus calls ION_IOC_FREE simultaneously.

cpu 0                                   cpu 1
-------------------------------------------------------
ion_handle_get_by_id()
(ref == 2)
                            ion_handle_get_by_id()
                            (ref == 3)

ion_free()
(ref == 2)

ion_handle_put()
(ref == 1)

                            ion_free()
                            (ref == 0 so ion_handle_destroy() is
                            called
                            and the handle is freed.)

                            ion_handle_put() is called and it
                            decreases the slub's next free pointer

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a mis-aligned access to the
next free pointer.(kmalloc returns a pointer like
ffffc0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
Reviewed-by: Laura Abbott 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

index 7ff2a7ec871f..33b390e7ea31

staging: android: ion: Set the length of the DMA sg entries in buffer

2016-04-20T06:42:16+00:00

commit 70bc916b2c80913753fb188d4daee50a64d21ba0 upstream.

ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.

Signed-off-by: Liviu Dudau 
Signed-off-by: Jon Medhurst 
Acked-by: Laura Abbott 
Cc: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion_test: fix check of platform_device_register_simple() error code

2016-04-12T16:08:48+00:00

commit ccbc2a9e7878ff09bcaed4893c2a2d3adbb797e2 upstream.

On error platform_device_register_simple() returns ERR_PTR() value,
check for NULL always fails. The change corrects the check itself and
propagates the returned error upwards.

Fixes: 81fb0b901397 ("staging: android: ion_test: unregister the platform device")
Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Greg Kroah-Hartman

Revert "scatterlist: use sg_phys()"

2015-12-15T20:54:06+00:00

commit db0fa0cb0157 "scatterlist: use sg_phys()" did replacements of
the form:

    phys_addr_t phys = page_to_phys(sg_page(s));
    phys_addr_t phys = sg_phys(s) & PAGE_MASK;

However, this breaks platforms where sizeof(phys_addr_t) >
sizeof(unsigned long).  Revert for 4.3 and 4.4 to make room for a
combined helper in 4.5.

Cc: 
Cc: Jens Axboe 
Cc: Christoph Hellwig 
Cc: Russell King 
Cc: David Woodhouse 
Cc: Andrew Morton 
Fixes: db0fa0cb0157 ("scatterlist: use sg_phys()")
Suggested-by: Joerg Roedel 
Reported-by: Vitaly Lavrov 
Signed-off-by: Dan Williams

mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

2015-11-07T01:50:42+00:00

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.

Signed-off-by: Mel Gorman 
Acked-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Vitaly Wool 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

staging: ion: Remove explicit NULL comparison

2015-10-25T02:26:59+00:00

Rewrite explicit NULL comparison in its simpler form.

@NULL_REPLACE@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Muhammad Falak R Wani 
Signed-off-by: Greg Kroah-Hartman