* [PATCH] kthread: fix use-after-free if kthread fork fails
@ 2017-05-05 16:20 Vegard Nossum
2017-05-05 16:44 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Vegard Nossum @ 2017-05-05 16:20 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, Frederic Weisbecker, Jamie Iles,
Vegard Nossum, Oleg Nesterov, Peter Zijlstra, Thomas Gleixner,
Andy Lutomirski
If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but
fails in copy_process() between calling dup_task_struct() and setting
p->set_child_tid, then the value of p->set_child_tid will be inherited
from the parent and get prematurely freed by free_kthread_struct().
kthread()
- worker_thread()
- process_one_work()
| - call_usermodehelper_exec_work()
| - kernel_thread()
| - _do_fork()
| - copy_process()
| - dup_task_struct()
| - arch_dup_task_struct()
| - tsk->set_child_tid = current->set_child_tid // implied
| - ...
| - goto bad_fork_*
| - ...
| - free_task(tsk)
| - free_kthread_struct(tsk)
| - kfree(tsk->set_child_tid)
- ...
- schedule()
- __schedule()
- wq_worker_sleeping()
- kthread_data(task)->flags // UAF
The problem started showing up with commit 1da5c46fa965 since it reused
->set_child_tid for the kthread worker data.
A better long-term solution might be to get rid of the ->set_child_tid
abuse. The comment in set_kthread_struct() also looks slightly wrong.
Fixes: 1da5c46fa965ff90f5ffc080b6ab3fae5e227bc3 ("kthread: Make struct kthread kmalloc'ed")
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Debugged-by: Jamie Iles <jamie.iles@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
---
kernel/fork.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index dd5a371c392a..fbdc29365b83 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -518,6 +518,13 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
atomic_set(&tsk->stack_refcount, 1);
#endif
+ /*
+ * Forking kthreads (e.g. usermodehelper) should not inherit this
+ * field since it's a pointer to a 'struct kthread' which is not
+ * reference counted.
+ */
+ tsk->set_child_tid = NULL;
+
if (err)
goto free_stack;
--
2.12.0.rc0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] kthread: fix use-after-free if kthread fork fails
2017-05-05 16:20 [PATCH] kthread: fix use-after-free if kthread fork fails Vegard Nossum
@ 2017-05-05 16:44 ` Oleg Nesterov
2017-05-05 17:17 ` Vegard Nossum
0 siblings, 1 reply; 4+ messages in thread
From: Oleg Nesterov @ 2017-05-05 16:44 UTC (permalink / raw)
To: Vegard Nossum
Cc: linux-kernel, Greg Kroah-Hartman, Frederic Weisbecker,
Jamie Iles, Peter Zijlstra, Thomas Gleixner, Andy Lutomirski
On 05/05, Vegard Nossum wrote:
>
> If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but
> fails in copy_process() between calling dup_task_struct() and setting
> p->set_child_tid, then the value of p->set_child_tid will be inherited
> from the parent and get prematurely freed by free_kthread_struct().
Aaah... thanks!
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -518,6 +518,13 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
> atomic_set(&tsk->stack_refcount, 1);
> #endif
>
> + /*
> + * Forking kthreads (e.g. usermodehelper) should not inherit this
> + * field since it's a pointer to a 'struct kthread' which is not
> + * reference counted.
> + */
> + tsk->set_child_tid = NULL;
> +
Can't we just move both
p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
/*
* Clear TID on mm_release()?
*/
p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr : NULL;
lines here?
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] kthread: fix use-after-free if kthread fork fails
2017-05-05 16:44 ` Oleg Nesterov
@ 2017-05-05 17:17 ` Vegard Nossum
2017-05-06 19:51 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Vegard Nossum @ 2017-05-05 17:17 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-kernel, Greg Kroah-Hartman, Frederic Weisbecker,
Jamie Iles, Peter Zijlstra, Thomas Gleixner, Andy Lutomirski
[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]
On 05/05/17 18:44, Oleg Nesterov wrote:
> On 05/05, Vegard Nossum wrote:
>>
>> If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but
>> fails in copy_process() between calling dup_task_struct() and setting
>> p->set_child_tid, then the value of p->set_child_tid will be inherited
>> from the parent and get prematurely freed by free_kthread_struct().
>
> Aaah... thanks!
>
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -518,6 +518,13 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
>> atomic_set(&tsk->stack_refcount, 1);
>> #endif
>>
>> + /*
>> + * Forking kthreads (e.g. usermodehelper) should not inherit this
>> + * field since it's a pointer to a 'struct kthread' which is not
>> + * reference counted.
>> + */
>> + tsk->set_child_tid = NULL;
>> +
>
> Can't we just move both
>
> p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
> /*
> * Clear TID on mm_release()?
> */
> p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr : NULL;
>
> lines here?
clone_flags is not available in dup_task_struct(), but we could move
those lines higher in copy_process(). The reason we didn't do it was
that we thought it was a little fragile/unobvious that this has to
happen before free_task() is called and that it was safer to clear it in
dup_task_struct() (which also contains zeroing of other fields).
The newly attached patch has been tested and seems to work, if you
prefer it.
Vegard
[-- Attachment #2: set_child_tid.patch --]
[-- Type: text/x-patch, Size: 1093 bytes --]
diff --git a/kernel/fork.c b/kernel/fork.c
index fbdc29365b83..c52e22fdf7ca 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1561,6 +1561,18 @@ static __latent_entropy struct task_struct *copy_process(
if (!p)
goto fork_out;
+ /*
+ * This _must_ happen before we call free_task(), i.e. before we jump
+ * to any of the bad_fork_* labels. This is to avoid freeing
+ * p->set_child_tid which is (ab)used as a kthread's data pointer for
+ * kernel threads (PF_KTHREAD).
+ */
+ p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
+ /*
+ * Clear TID on mm_release()?
+ */
+ p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr : NULL;
+
ftrace_graph_init_task(p);
rt_mutex_init_task(p);
@@ -1727,11 +1739,6 @@ static __latent_entropy struct task_struct *copy_process(
}
}
- p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
- /*
- * Clear TID on mm_release()?
- */
- p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr : NULL;
#ifdef CONFIG_BLOCK
p->plug = NULL;
#endif
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] kthread: fix use-after-free if kthread fork fails
2017-05-05 17:17 ` Vegard Nossum
@ 2017-05-06 19:51 ` Oleg Nesterov
0 siblings, 0 replies; 4+ messages in thread
From: Oleg Nesterov @ 2017-05-06 19:51 UTC (permalink / raw)
To: Vegard Nossum
Cc: linux-kernel, Greg Kroah-Hartman, Frederic Weisbecker,
Jamie Iles, Peter Zijlstra, Thomas Gleixner, Andy Lutomirski
On 05/05, Vegard Nossum wrote:
>
> On 05/05/17 18:44, Oleg Nesterov wrote:
> >
> >Can't we just move both
> >
> > p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
> > /*
> > * Clear TID on mm_release()?
> > */
> > p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? child_tidptr : NULL;
> >
> >lines here?
>
> clone_flags is not available in dup_task_struct(), but we could move
> those lines higher in copy_process().
Yes, yes, this is what I meant.
> The newly attached patch has been tested and seems to work, if you
> prefer it.
Yes, please, this loos a bit better simply because we do not need to set it twice.
And I agree this needs cleanups. Even if we forget about this particular problem
and the usage of set_child_tid, we should add copy_misc() which should absorb a
lot of chaotic initializations from copy_process() imo.
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-06 19:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-05 16:20 [PATCH] kthread: fix use-after-free if kthread fork fails Vegard Nossum
2017-05-05 16:44 ` Oleg Nesterov
2017-05-05 17:17 ` Vegard Nossum
2017-05-06 19:51 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).