Messages in this thread | | | Subject | Re: [PATCH 1/5] ptrace: Prepare to fix racy accesses on task breakpoints | From | Will Deacon <> | Date | Mon, 11 Apr 2011 11:47:57 +0100 |
| |
Hi Frederic,
On Fri, 2011-04-08 at 18:34 +0100, Frederic Weisbecker wrote: > When a task is traced and is in a stopped state, the tracer > may execute a ptrace request to examine the tracee state and > get its task struct. Right after, the tracee can be killed > and thus its breakpoints released. > This can happen concurrently when the tracer is in the middle > of reading or modifying these breakpoints, leading to dereferencing > a freed pointer.
Oo, that's nasty. Would an alternative solution be to free the breakpoints only when the task_struct usage count is zero?
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c > index 0fc1eed..dc7ab65 100644 > --- a/kernel/ptrace.c > +++ b/kernel/ptrace.c > @@ -22,6 +22,7 @@ > #include <linux/syscalls.h> > #include <linux/uaccess.h> > #include <linux/regset.h> > +#include <linux/hw_breakpoint.h> > > > /* > @@ -879,3 +880,19 @@ asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid, > return ret; > } > #endif /* CONFIG_COMPAT */ > + > +#ifdef CONFIG_HAVE_HW_BREAKPOINT > +int ptrace_get_breakpoints(struct task_struct *tsk) > +{ > + if (atomic_inc_not_zero(&tsk->ptrace_bp_refcnt)) > + return 0; > + > + return -1; > +}
Would it be better to return -ESRCH here instead?
Will
| |