Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: BUG: bad usercopy in __check_object_size (2)
To:     keescook@chromium.org, keescook@google.com
References: <000000000000e16cba057549aab6@google.com>
Cc:     syzbot <syzbot+a3c9d2673837ccc0f22b@syzkaller.appspotmail.com>,
        crecklin@redhat.com, dvyukov@google.com, hpa@zytor.com,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org,
        mingo@redhat.com, syzkaller-bugs@googlegroups.com,
        tglx@linutronix.de, x86@kernel.org
From:   Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Message-ID: <14d5bccf-f12d-0fc1-eddc-9fb24dc0cf14@I-love.SAKURA.ne.jp>
Date:   Sat, 8 Sep 2018 01:17:44 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <000000000000e16cba057549aab6@google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2018/09/08 0:29, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
> 
> HEAD commit:    28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree:       bpf
> console output: https://syzkaller.appspot.com/x/log.txt?x=124e64d1400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=62e9b447c16085cf
> dashboard link: https://syzkaller.appspot.com/bug?extid=a3c9d2673837ccc0f22b
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=179f9cd1400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11b3e8be400000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a3c9d2673837ccc0f22b@syzkaller.appspotmail.com
> 
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440479
> usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 64)!

Kees, is this because check_page_span() is failing to allow on-stack variable

   u8 opcodes[OPCODE_BUFSIZE];

which by chance crossed PAGE_SIZE boundary?