Kees Cook <keesc...@chromium.org> writes:
> On Mon, Mar 11, 2013 at 12:28 PM, Oleg Nesterov <o...@redhat.com> wrote:
>> On 03/11, Kees Cook wrote:
>>>
>>> When the new signal handlers are set up for a fork, the location of
>>> sa_restorer is not cleared, leaking a parent process's address space
>>> location to children. This allows for a potential bypass of the parent's
>>> ASLR by examining the sa_restorer value returned when calling sigaction().
>>
>> I don't understand.
>>
>> fork() should not change restorer/etc, and the child has the same address
>> space anyway. There is no any leak and the patch can't make any difference
>> in this case because flush_signal_handlers() is not called by fork().
>
> I probably failed to explain this correctly. From the perspective of
> what should be considered "secret", it only matters across the exec,
> not the fork (since the VMAs haven't changed until the exec). But the
> info leak is easy to see, and this patch fixes it. As you say, since
> other things were reset, so should sa_restorer.
At the very least please correct the explanation in your patch
description.
Too often I have had seen a confused patch description, indicate
confusion elsewhere in the patch. Let's make it easy for reviewers
and future bisectors to understand what is intended.
>>> @@ -485,6 +485,9 @@ flush_signal_handlers(struct task_struct *t, int
>>> force_default)
>>> if (force_default || ka->sa.sa_handler != SIG_IGN)
>>> ka->sa.sa_handler = SIG_DFL;
>>> ka->sa.sa_flags = 0;
>>> +#ifdef __ARCH_HAS_SA_RESTORER
>>> + ka->sa.sa_restorer = NULL;
>>> +#endif
Also I am inclined to suggest this should be an inline function in a
header.
clear_sa_restorer(ka);
Just so we don't litter the code with #ifdefs.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
