Re: [Qemu-devel] [PATCH v3] aio: Fix use-after-free in cancellation path

[Stefan Hajnoczi]

On Wed, May 21, 2014 at 10:42:13AM +0800, Fam Zheng wrote:
> The current flow of canceling a thread from THREAD_ACTIVE state is:
> 
>   1) Caller wants to cancel a request, so it calls thread_pool_cancel.
> 
>   2) thread_pool_cancel waits on the conditional variable
>      elem->check_cancel.
> 
>   3) The worker thread changes state to THREAD_DONE once the task is
>      done, and notifies elem->check_cancel to allow thread_pool_cancel
>      to continue execution, and signals the notifier (pool->notifier) to
>      allow callback function to be called later. But because of the
>      global mutex, the notifier won't get processed until step 4) and 5)
>      are done.
> 
>   4) thread_pool_cancel continues, leaving the notifier signaled, it
>      just returns to caller.
> 
>   5) Caller thinks the request is already canceled successfully, so it
>      releases any related data, such as freeing elem->common.opaque.
> 
>   6) In the next main loop iteration, the notifier handler,
>      event_notifier_ready, is called. It finds the canceled thread in
>      THREAD_DONE state, so calls elem->common.cb, with an (likely)
>      dangling opaque pointer. This is a use-after-free.
> 
> Fix it by calling event_notifier_ready before leaving
> thread_pool_cancel.
> 
> Test case update: This change will let cancel complete earlier than
> test-thread-pool.c expects, so update the code to check this case: if
> it's already done, done_cb sets .aiocb to NULL, skip calling
> bdrv_aio_cancel on them.
> 
> Reported-by: Ulrich Obergfell <address@hidden>
> Suggested-by: Paolo Bonzini <address@hidden>
> Signed-off-by: Fam Zheng <address@hidden>
> 
> ---
> v3: Call event_notifier_ready after unlock.
> ---
>  tests/test-thread-pool.c | 2 +-
>  thread-pool.c            | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan