diff options
author | Peter Zijlstra <peterz@infradead.org> | 2021-04-20 10:18:17 +0200 |
---|---|---|
committer | Peter Zijlstra <peterz@infradead.org> | 2021-04-21 13:55:42 +0200 |
commit | 3a7956e25e1d7b3c148569e78895e1f3178122a9 (patch) | |
tree | 3fed8e39328534e9aa499002bb4d8890bb75eac9 /kernel/cpu.c | |
parent | ad789f84c9a145f8a18744c0387cec22ec51651e (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) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <Valentin.Schneider@arm.com>
Link: https://lkml.kernel.org/r/YH6WJc825C4P0FCK@hirez.programming.kicks-ass.net
Diffstat (limited to 'kernel/cpu.c')
0 files changed, 0 insertions, 0 deletions