On Mon, Sep 28, 2015 at 12:23 PM, Borislav Petkov <[email protected]> wrote: > On Mon, Sep 28, 2015 at 11:49:18AM +0200, Dmitry Vyukov wrote: >> Original code did: >> >> if (p->thread.sp < stack || p->thread.sp >= stack+THREAD_SIZE) >> return 0; >> fp = *(u64 *)(p->thread.sp); >> >> p->thread.sp can change concurrently. >> So we could check that p->thread.sp is within stack bounds, but then >> dereference another value (which is already outside of bounds). > > Right, we do deref it. I realized that after hitting "Send" :\ > > Which begs another, probably also stupid, question: > > What guarantees the task won't disappear after we've checked p? > > I.e., after this: > > if (!p || p == current || p->state == TASK_RUNNING) > return 0;
I have not checked, but I would expect that it is caller's responsibility. There is generally no way to magically resurrect a pointer to a freed object passed in. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
