[Mesa-dev] [PATCH] anv/allocator: Loosen the size restriction on imported BOs
Jason Ekstrand
jason at jlekstrand.net
Thu Sep 7 21:31:15 UTC 2017
Seems reasonable
Reviewed-by: Jason Ekstrand <jason at jlekstrand.net>
On Wed, Aug 2, 2017 at 3:37 PM, Kevin Strasser <kevin.strasser at intel.com>
wrote:
> It's possible for a buffer manager to issue the application a BO that is
> larger than what is requested. The out-of-bounds access issue would only
> apply in cases where the size of the imported buffer exceeds that of the
> underlying BO, as such we should only reject import requests sizes that
> exceed the actual size of the BO.
>
> Signed-off-by: Kevin Strasser <kevin.strasser at intel.com>
> ---
> src/intel/vulkan/anv_allocator.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_
> allocator.c
> index efaaebc..1fb3756 100644
> --- a/src/intel/vulkan/anv_allocator.c
> +++ b/src/intel/vulkan/anv_allocator.c
> @@ -1291,16 +1291,16 @@ anv_bo_cache_import(struct anv_device *device,
> }
> __sync_fetch_and_add(&bo->refcount, 1);
> } else {
> - /* For security purposes, we reject BO imports where the size does
> not
> - * match exactly. This prevents a malicious client from passing a
> - * buffer to a trusted client, lying about the size, and telling the
> + /* For security purposes, we reject BO imports where the requested
> size
> + * exceeds the actual size. This prevents a malicious client from
> passing
> + * a buffer to a trusted client, lying about the size, and telling
> the
> * trusted client to try and texture from an image that goes
> * out-of-bounds. This sort of thing could lead to GPU hangs or
> worse
> * in the trusted client. The trusted client can protect itself
> against
> * this sort of attack but only if it can trust the buffer size.
> */
> off_t import_size = lseek(fd, 0, SEEK_END);
> - if (import_size == (off_t)-1 || import_size != size) {
> + if (import_size == (off_t)-1 || import_size < size) {
> anv_gem_close(device, gem_handle);
> pthread_mutex_unlock(&cache->mutex);
> return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR);
> --
> 2.7.4
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170907/2266f139/attachment.html>
More information about the mesa-dev
mailing list