linux-kernel - Re: BUG: bad usercopy in __check_object

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 8 Sep 2018 01:17:44 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     keescook@...omium.org, keescook@...gle.com
Cc:     syzbot <syzbot+a3c9d2673837ccc0f22b@...kaller.appspotmail.com>,
        crecklin@...hat.com, dvyukov@...gle.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, luto@...nel.org,
        mingo@...hat.com, syzkaller-bugs@...glegroups.com,
        tglx@...utronix.de, x86@...nel.org
Subject: Re: BUG: bad usercopy in __check_object_size (2)

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@...kaller.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?