Re: [PATCH] notify_parent and ptrace cleanup

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Roland McGrath <roland@redhat.com> writes:

> I believe I understand the case you are referring to now that I've looked
> at it.  But I think this is the first I've heard about this issue.

ptrace() is frangible, and racy. And looks like few things can't improve
without user visible change. So, I'm thinking I would like to rewrite
it by another interface.

> While ptrace_getsiginfo is examining child->last_siginfo, another processor
> could be resuming that child via SIGCONT so that it clears last_siginfo and
> reuses the stack space it was pointing to.  With the right timing of the
> race, the ptrace_getsiginfo call could crash with an unexpected kernel-mode
> null pointer reference.  This is what you are talking about, right?

Yes. Or siginfo is changed while it's using.


[...]

Quick read... Looks good to me

Thanks.

> +	read_lock_irq(&tasklist_lock); /* Protects child->sighand.  */
                 ^^^^
_irq is unneeded?

> +	if (unlikely(child->sighand == NULL))
> +		ret = -EINVAL;
> +	else {
> +		spin_lock_irq(&child->sighand->siglock);
> +		if (child->last_siginfo == NULL)
> +			ret = -EINVAL;
> +		else
> +			*child->last_siginfo = info;
> +		spin_unlock_irq(&child->sighand->siglock);
> +	}
> +	read_unlock_irq(&tasklist_lock);
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>