]> www.infradead.org Git - users/dwmw2/linux.git/commit
tee: optee: avoid possible double list_del()
authorZhizhou Zhang <zhizhouzhang@asrmicro.com>
Wed, 21 Nov 2018 03:01:43 +0000 (11:01 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 12 Feb 2019 19:02:18 +0000 (20:02 +0100)
commit50efaf4b1817c2f2c2b09015a1e18194a3573e39
tree748b1c8bb405180543c19b396a949896e7e33bdb
parent9565dd2144cf205730e07a714db93c168995dd9c
tee: optee: avoid possible double list_del()

[ Upstream commit b2d102bd0146d9eb1fa630ca0cd19a15ef2f74c8 ]

This bug occurs when:

- a new request arrives, one thread(let's call it A) is pending in
  optee_supp_req() with req->busy is initial value false.

- tee-supplicant is killed, then optee_supp_release() is called, this
  function calls list_del(&req->link), and set supp->ctx to NULL. And
  it also wake up process A.

- process A continues, it firstly checks supp->ctx which is NULL,
  then checks req->busy which is false, at last run list_del(&req->link).
  This triggers double list_del() and results kernel panic.

For solve this problem, we rename req->busy to req->in_queue, and
associate it with state of whether req is linked to supp->reqs. So we
can just only check req->in_queue to make decision calling list_del()
or not.

Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/tee/optee/supp.c