Commit 523b16e6 authored by Jens Wiklander's avatar Jens Wiklander Committed by Zheng Zengkai
Browse files

tee: handle lookup of shm with reference count 0

stable inclusion
from stable-v5.10.89
commit c05d8f66ec3470e5212c4d08c46d6cb5738d600d
bugzilla: 186027 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-44733

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c05d8f66ec3470e5212c4d08c46d6cb5738d600d



--------------------------------

commit dfd0743f upstream.

Since the tee subsystem does not keep a strong reference to its idle
shared memory buffers, it races with other threads that try to destroy a
shared memory through a close of its dma-buf fd or by unmapping the
memory.

In tee_shm_get_from_id() when a lookup in teedev->idr has been
successful, it is possible that the tee_shm is in the dma-buf teardown
path, but that path is blocked by the teedev mutex. Since we don't have
an API to tell if the tee_shm is in the dma-buf teardown path or not we
must find another way of detecting this condition.

Fix this by doing the reference counting directly on the tee_shm using a
new refcount_t refcount field. dma-buf is replaced by using
anon_inode_getfd() instead, this separates the life-cycle of the
underlying file from the tee_shm. tee_shm_put() is updated to hold the
mutex when decreasing the refcount to 0 and then remove the tee_shm from
teedev->idr before releasing the mutex. This means that the tee_shm can
never be found unless it has a refcount larger than 0.

Fixes: 967c9cca ("tee: generic TEE subsystem")
Cc: stable@vger.kernel.org
Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: default avatarLars Persson <larper@axis.com>
Reviewed-by: default avatarSumit Garg <sumit.garg@linaro.org>
Reported-by: default avatarPatrik Lantz <patrik.lantz@axis.com>
Signed-off-by: default avatarJens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
parent b5f52fa7
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment