On 1/18/19 12:37 PM, Liam Mark wrote:
> 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
>
The window for this seems really small, but it does seem technically
possible, good find. for what it's worth:
Acked-by: Andrew F. Davis <a...@ti.com>
> 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 <lm...@codeaurora.org>
> ---
> drivers/staging/android/ion/ion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index a0802de8c3a1..6f5afab7c1a1 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -248,10 +248,10 @@ static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
> struct ion_dma_buf_attachment *a = attachment->priv;
> struct ion_buffer *buffer = dmabuf->priv;
>
> - free_duped_table(a->table);
> mutex_lock(&buffer->lock);
> list_del(&a->list);
> mutex_unlock(&buffer->lock);
> + free_duped_table(a->table);
>
> kfree(a);
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
