From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Vyukov Subject: Re: sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats Date: Mon, 16 Jan 2017 15:56:06 +0100 Message-ID: References: <20170115203515.GA6274@neilslaptop.think-freely.org> <20170116135743.GC30105@hmswarspite.think-freely.org> <063D6719AE5E284EB5DD2968C1650D6DB0264AD2@AcuExch.aculab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Neil Horman , Vladislav Yasevich , David Miller , "linux-sctp@vger.kernel.org" , netdev , LKML , Kees Cook , syzkaller To: David Laight Return-path: Received: from mail-lf0-f43.google.com ([209.85.215.43]:35182 "EHLO mail-lf0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750831AbdAPO43 (ORCPT ); Mon, 16 Jan 2017 09:56:29 -0500 Received: by mail-lf0-f43.google.com with SMTP id n124so16518219lfd.2 for ; Mon, 16 Jan 2017 06:56:28 -0800 (PST) In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0264AD2@AcuExch.aculab.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, Jan 16, 2017 at 3:50 PM, David Laight 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.