path: root/lib
diff options
authorPeter Zijlstra <>2021-04-20 10:18:17 +0200
committerPeter Zijlstra <>2021-04-21 13:55:42 +0200
commit3a7956e25e1d7b3c148569e78895e1f3178122a9 (patch)
tree3fed8e39328534e9aa499002bb4d8890bb75eac9 /lib
parentad789f84c9a145f8a18744c0387cec22ec51651e (diff)
kthread: Fix PF_KTHREAD vs to_kthread() race
The kthread_is_per_cpu() construct relies on only being called on PF_KTHREAD tasks (per the WARN in to_kthread). This gives rise to the following usage pattern: if ((p->flags & PF_KTHREAD) && kthread_is_per_cpu(p)) However, as reported by syzcaller, this is broken. The scenario is: CPU0 CPU1 (running p) (p->flags & PF_KTHREAD) // true begin_new_exec() me->flags &= ~(PF_KTHREAD|...); kthread_is_per_cpu(p) to_kthread(p) WARN(!(p->flags & PF_KTHREAD) <-- *SPLAT* Introduce __to_kthread() that omits the WARN and is sure to check both values. Use this to remove the problematic pattern for kthread_is_per_cpu() and fix a number of other kthread_*() functions that have similar issues but are currently not used in ways that would expose the problem. Notably kthread_func() is only ever called on 'current', while kthread_probe_data() is only used for PF_WQ_WORKER, which implies the task is from kthread_create*(). Fixes: ac687e6e8c26 ("kthread: Extract KTHREAD_IS_PER_CPU") Signed-off-by: Peter Zijlstra (Intel) <> Reviewed-by: Valentin Schneider <> Link:
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions