video: tegra: nvmap: Fix data race

Consider the following execution scenario, it can lead to a data race

Thread 1                    Thread 2
-------------------------------------------------------
NvRmMemHandleAllocAttr
NvRmMemGetFd
NvRmMemHandleFromFd         close(fd), NvRmMemHandleFree

When thread 1 is executing NvRmMemHandleFromFd while thread 2 is closing
the fd and freeing the handle, then following sequence will lead to
accessing a freed dma-buf and may lead to dereference issue.

- TH1: Get handle from fd and increment handle's refcount.
- TH2: Close the fd and start execution of NvRmMemHandleFree.
- TH2: Decrement ref's dup count, it will become 0, hence ref would be
freed and dma-buf as well, but as handle's refcount is incremented in
step 1, handle won't be freed.
- TH1: Resume HandleFromFd part, call to nvmap_duplicate_handle. Ref is
already freed, so generate new ref and increment dma-buf's count but as
dma-buf is freed already, accessing dma-buf will lead to dereferene
issue. Hence, we need to add a null check here and return error value in
such scenario.

Also, add check for return value of nvmap_handle_get, at missing places.

Bug 4214453

Change-Id: Ib6ef66b4a7126bef2ed1dbb48643445a4ded1bab
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2994962
(cherry picked from commit 7ba6a3abfe65f7cffeeb4004cf0868468121fc32)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2994440
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>

drivers/video/tegra/nvmap/nvmap_dmabuf.c

@@ -624,7 +624,11 @@ struct dma_buf *__nvmap_make_dmabuf(struct nvmap_client *client,
 		err = PTR_ERR(dmabuf);
 		goto err_export;
 	}
-	nvmap_handle_get(handle);
+
+	if (!nvmap_handle_get(handle)) {
+		err = -EINVAL;
+		goto err_export;
+	}
 
 	trace_nvmap_make_dmabuf(client->name, handle, dmabuf);
 	return dmabuf;