On 09/12/2018 10:29 AM, Jason Yan wrote:
> When the lldd is processing the complete sas task in interrupt and set
> the task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to
> be triggered at the same time. And smp_task_timedout() will complete the
> task wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may
> freed before lldd end the interrupt process. Thus a use-after-free will
> happen.
> 
> Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not
> set. And remove the check of the return value of the del_timer().
> 
> Reported-by: chenxiang <[email protected]>
> Signed-off-by: Jason Yan <[email protected]>
> CC: John Garry <[email protected]>
> CC: Johannes Thumshirn <[email protected]>
> CC: Ewan Milne <[email protected]>
> CC: Christoph Hellwig <[email protected]>
> CC: Tomas Henzl <[email protected]>
> CC: Dan Williams <[email protected]>
> CC: Hannes Reinecke <[email protected]>
> ---
>  drivers/scsi/libsas/sas_expander.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/libsas/sas_expander.c 
> b/drivers/scsi/libsas/sas_expander.c
> index 52222940d398..0d1f72752ca2 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -48,17 +48,16 @@ static void smp_task_timedout(struct timer_list *t)
>       unsigned long flags;
>  
>       spin_lock_irqsave(&task->task_state_lock, flags);
> -     if (!(task->task_state_flags & SAS_TASK_STATE_DONE))
> +     if (!(task->task_state_flags & SAS_TASK_STATE_DONE)) {
>               task->task_state_flags |= SAS_TASK_STATE_ABORTED;
> +             complete(&task->slow_task->completion);
> +     }
>       spin_unlock_irqrestore(&task->task_state_lock, flags);
> -
> -     complete(&task->slow_task->completion);
>  }
>  
>  static void smp_task_done(struct sas_task *task)
>  {
> -     if (!del_timer(&task->slow_task->timer))
> -             return;
> +     del_timer(&task->slow_task->timer);
>       complete(&task->slow_task->completion);
>  }
>  
> 
Reviewed-by: Hannes Reinecke <[email protected]>

Cheers,

Hannes

Reply via email to