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. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
