If the parent has no entry in group_list, child_ctx will not be
allocated, which will lead dereference of a NULL child_ctx.
Signed-off-by: Liming Wang <[email protected]>
---
kernel/perf_event.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 5b987b4..3664c4b 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -5126,6 +5126,8 @@ int perf_event_init_task(struct task_struct *child)
*/
mutex_lock(&parent_ctx->mutex);
+ if (list_empty(&parent_ctx->group_list))
+ goto exit;
/*
* We dont have to disable NMIs - we are only looking at
* the list, not manipulating it:
--
1.6.0.3
On Wed, 2009-12-30 at 19:28 +0800, Liming Wang wrote:
> If the parent has no entry in group_list, child_ctx will not be
> allocated, which will lead dereference of a NULL child_ctx.
That changelog sucks.
Best I can make of it is that there is a race where the parent gets his
context instantiated and we manage to get the mutex before the other
thread manages to add the first event.
Then we observe parent_event_ctx but have an empty list.
Is that it?
In that case, would it not be better to change the if (inherited_all)
condition to if (inherited_all && child_ctx) ?
> Signed-off-by: Liming Wang <[email protected]>
> ---
> kernel/perf_event.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/perf_event.c b/kernel/perf_event.c
> index 5b987b4..3664c4b 100644
> --- a/kernel/perf_event.c
> +++ b/kernel/perf_event.c
> @@ -5126,6 +5126,8 @@ int perf_event_init_task(struct task_struct *child)
> */
> mutex_lock(&parent_ctx->mutex);
>
> + if (list_empty(&parent_ctx->group_list))
> + goto exit;
> /*
> * We dont have to disable NMIs - we are only looking at
> * the list, not manipulating it:
Peter Zijlstra wrote:
> On Wed, 2009-12-30 at 19:28 +0800, Liming Wang wrote:
>> If the parent has no entry in group_list, child_ctx will not be
>> allocated, which will lead dereference of a NULL child_ctx.
>
> That changelog sucks.
Sorry the changelog is too simple.
>
> Best I can make of it is that there is a race where the parent gets his
> context instantiated and we manage to get the mutex before the other
> thread manages to add the first event.
>
> Then we observe parent_event_ctx but have an empty list.
>
> Is that it?
I didn't find this case.
In my case, if I perf record a existing process with "--pid" and finish record,
and if later the recorded process forks a process, the condition will occur.
Liming Wang
>
> In that case, would it not be better to change the if (inherited_all)
> condition to if (inherited_all && child_ctx) ?
>
>> Signed-off-by: Liming Wang <[email protected]>
>> ---
>> kernel/perf_event.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/perf_event.c b/kernel/perf_event.c
>> index 5b987b4..3664c4b 100644
>> --- a/kernel/perf_event.c
>> +++ b/kernel/perf_event.c
>> @@ -5126,6 +5126,8 @@ int perf_event_init_task(struct task_struct *child)
>> */
>> mutex_lock(&parent_ctx->mutex);
>>
>> + if (list_empty(&parent_ctx->group_list))
>> + goto exit;
>> /*
>> * We dont have to disable NMIs - we are only looking at
>> * the list, not manipulating it:
>
>
>
Peter Zijlstra wrote:
> On Wed, 2009-12-30 at 22:36 +0800, Wang Liming wrote:
>>> Best I can make of it is that there is a race where the parent gets his
>>> context instantiated and we manage to get the mutex before the other
>>> thread manages to add the first event.
>>>
>>> Then we observe parent_event_ctx but have an empty list.
>>>
>>> Is that it?
>> I didn't find this case.
>> In my case, if I perf record a existing process with "--pid" and finish record,
>> and if later the recorded process forks a process, the condition will occur.
>
> Ah, right, that will lead to the same state, since closing the last
> counter will not remove the context.
>
> Does the below also fix your issue?
Yes, it's OK to me.
Thanks a lot!
Liming Wang
>
> ---
> Subject: perf: Fix NULL deref in inheritance code
> From: Peter Zijlstra <[email protected]>
> Date: Wed Dec 30 16:00:35 CET 2009
>
> Liming found a NULL deref when a task has a perf context but no counters
> when it forks.
>
> This can occur in two cases, a race during construction where the fork hits
> after installing the context but before the first counter gets inserted, or
> more reproducably, a fork after the last counter is closed (which leaves the
> context around).
>
> CC: [email protected]
> Reported-by: Wang Liming <[email protected]>
> Signed-off-by: Peter Zijlstra <[email protected]>
> ---
> kernel/perf_event.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/kernel/perf_event.c
> ===================================================================
> --- linux-2.6.orig/kernel/perf_event.c
> +++ linux-2.6/kernel/perf_event.c
> @@ -5149,7 +5149,7 @@ int perf_event_init_task(struct task_str
> GFP_KERNEL);
> if (!child_ctx) {
> ret = -ENOMEM;
> - goto exit;
> + break;
> }
>
> __perf_event_init_context(child_ctx, child);
> @@ -5165,7 +5165,7 @@ int perf_event_init_task(struct task_str
> }
> }
>
> - if (inherited_all) {
> + if (child_ctx && inherited_all) {
> /*
> * Mark the child context as a clone of the parent
> * context, or of whatever the parent is a clone of.
> @@ -5185,7 +5185,6 @@ int perf_event_init_task(struct task_str
> get_ctx(child_ctx->parent_ctx);
> }
>
> -exit:
> mutex_unlock(&parent_ctx->mutex);
>
> perf_unpin_context(parent_ctx);
>
>
>
On Wed, 2009-12-30 at 22:36 +0800, Wang Liming wrote:
> > Best I can make of it is that there is a race where the parent gets his
> > context instantiated and we manage to get the mutex before the other
> > thread manages to add the first event.
> >
> > Then we observe parent_event_ctx but have an empty list.
> >
> > Is that it?
> I didn't find this case.
> In my case, if I perf record a existing process with "--pid" and finish record,
> and if later the recorded process forks a process, the condition will occur.
Ah, right, that will lead to the same state, since closing the last
counter will not remove the context.
Does the below also fix your issue?
---
Subject: perf: Fix NULL deref in inheritance code
From: Peter Zijlstra <[email protected]>
Date: Wed Dec 30 16:00:35 CET 2009
Liming found a NULL deref when a task has a perf context but no counters
when it forks.
This can occur in two cases, a race during construction where the fork hits
after installing the context but before the first counter gets inserted, or
more reproducably, a fork after the last counter is closed (which leaves the
context around).
CC: [email protected]
Reported-by: Wang Liming <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
---
kernel/perf_event.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/kernel/perf_event.c
+++ linux-2.6/kernel/perf_event.c
@@ -5149,7 +5149,7 @@ int perf_event_init_task(struct task_str
GFP_KERNEL);
if (!child_ctx) {
ret = -ENOMEM;
- goto exit;
+ break;
}
__perf_event_init_context(child_ctx, child);
@@ -5165,7 +5165,7 @@ int perf_event_init_task(struct task_str
}
}
- if (inherited_all) {
+ if (child_ctx && inherited_all) {
/*
* Mark the child context as a clone of the parent
* context, or of whatever the parent is a clone of.
@@ -5185,7 +5185,6 @@ int perf_event_init_task(struct task_str
get_ctx(child_ctx->parent_ctx);
}
-exit:
mutex_unlock(&parent_ctx->mutex);
perf_unpin_context(parent_ctx);
Commit-ID: 05cbaa2853cdfc255fdd04e65a82bfe9208c4e52
Gitweb: http://git.kernel.org/tip/05cbaa2853cdfc255fdd04e65a82bfe9208c4e52
Author: Peter Zijlstra <[email protected]>
AuthorDate: Wed, 30 Dec 2009 16:00:35 +0100
Committer: Ingo Molnar <[email protected]>
CommitDate: Thu, 31 Dec 2009 13:11:31 +0100
perf: Fix NULL deref in inheritance code
Liming found a NULL deref when a task has a perf context but no
counters when it forks.
This can occur in two cases, a race during construction where
the fork hits after installing the context but before the first
counter gets inserted, or more reproducably, a fork after the
last counter is closed (which leaves the context around).
Reported-by: Wang Liming <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Paul Mackerras <[email protected]>
CC: <[email protected]>
LKML-Reference: <1262185684.7135.222.camel@laptop>
Signed-off-by: Ingo Molnar <[email protected]>
---
kernel/perf_event.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 03cc061..58ed1da 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -5148,7 +5148,7 @@ int perf_event_init_task(struct task_struct *child)
GFP_KERNEL);
if (!child_ctx) {
ret = -ENOMEM;
- goto exit;
+ break;
}
__perf_event_init_context(child_ctx, child);
@@ -5164,7 +5164,7 @@ int perf_event_init_task(struct task_struct *child)
}
}
- if (inherited_all) {
+ if (child_ctx && inherited_all) {
/*
* Mark the child context as a clone of the parent
* context, or of whatever the parent is a clone of.
@@ -5184,7 +5184,6 @@ int perf_event_init_task(struct task_struct *child)
get_ctx(child_ctx->parent_ctx);
}
-exit:
mutex_unlock(&parent_ctx->mutex);
perf_unpin_context(parent_ctx);