ubi: check kthread_should_stop() after the setting of task state
authorZhihao Cheng <chengzhihao1@huawei.com>
Mon, 1 Jun 2020 09:12:31 +0000 (17:12 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 5 Nov 2020 10:07:03 +0000 (11:07 +0100)
commit06aa51f617dab64dc5f1f94d70c1364c8afe5d9e
tree370a34b68b95cc9f03676f515299f8085fc65338
parentf9b29e6e034a16d48b48f3f5fb26c0910c333dcb
ubi: check kthread_should_stop() after the setting of task state

commit d005f8c6588efcfbe88099b6edafc6f58c84a9c1 upstream.

A detach hung is possible when a race occurs between the detach process
and the ubi background thread. The following sequences outline the race:

  ubi thread: if (list_empty(&ubi->works)...

  ubi detach: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags)
              => by kthread_stop()
              wake_up_process()
              => ubi thread is still running, so 0 is returned

  ubi thread: set_current_state(TASK_INTERRUPTIBLE)
              schedule()
              => ubi thread will never be scheduled again

  ubi detach: wait_for_completion()
              => hung task!

To fix that, we need to check kthread_should_stop() after we set the
task state, so the ubi thread will either see the stop bit and exit or
the task state is reset to runnable such that it isn't scheduled out
indefinitely.

Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: <stable@vger.kernel.org>
Fixes: 801c135ce73d5df1ca ("UBI: Unsorted Block Images")
Reported-by: syzbot+853639d0cb16c31c7a14@syzkaller.appspotmail.com
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/mtd/ubi/wl.c