Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats

[Kees Cook]

On Mon, Jan 16, 2017 at 6:56 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> On Mon, Jan 16, 2017 at 3:50 PM, David Laight <David.Laight@xxxxxxxxxx> wrote:
>> From: Dmitry Vyukov
>>> Sent: 16 January 2017 14:04
>>> >> >> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
>> ...
>>> >> The code also takes into account compound pages. As far as I
>>> >> understand the intention of the check is to effectively find
>>> >> out-of-bounds copies (e.g. goes beyond the current heap allocation). I
>>> >> would expect that stacks are allocated as compound pages and don't
>>> >> trigger this check. I don't see it is firing in other similar places.
>>> >>
>>> > Honestly, I'm not overly familiar with stack page allocation, at least not so
>>> > far as compound vs. single page allocation is concerned.  I suppose the question
>>> > your really asking here is: Have you found a case in which the syscall fuzzer
>>> > has forced the allocation of an insecure non-compound page on the stack, or is
>>> > this a false positive warning.  I can't provide the answer to that.
>>>
>>> Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
>>> Kees, is this a false positive?
>>
>> I'd guess that the kernel stack is (somehow) allocated page by page
>> rather than by a single multi-page allocate.
>> Or maybe vmalloc() isn't setting the required flag??
>
>
> Just in case, I don't have CONFIG_VMAP_STACK selected.
> If it is a generic issue, then CONFIG_HARDENED_USERCOPY_PAGESPAN looks
> considerably broken as there are tons of copies onto stack. I don't
> see what's special in this particular case.

There have been so many false positives on this option, even though it
is known not to be quite right, that I'll probably just remove it
entirely. It clearly needs much more work before it'll be useful, so
there's no reason to leave it in the kernel to confuse people. :)

-Kees

-- 
Kees Cook
Nexus Security