netdev - Re: BUG: unable to handle kernel paging request in bpf_int_jit

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]

Message-ID: <alpine.DEB.2.21.1806240849150.8650@nanos.tec.linutronix.de>
Date:   Sun, 24 Jun 2018 09:09:09 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     syzbot <syzbot+a4eb8c7766952a1ca872@...kaller.appspotmail.com>
cc:     ast@...nel.org, daniel@...earbox.net,
        David Miller <davem@...emloft.net>,
        "H. Peter Anvin" <hpa@...or.com>, kuznet@....inr.ac.ru,
        LKML <linux-kernel@...r.kernel.org>, mingo@...hat.com,
        netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        x86@...nel.org, yoshfuji@...ux-ipv6.org,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: BUG: unable to handle kernel paging request in
 bpf_int_jit_compile

On Sat, 23 Jun 2018, syzbot wrote:
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a4eb8c7766952a1ca872@...kaller.appspotmail.com
> 
> RAX: ffffffffffffffda RBX: 0000000001429914 RCX: 0000000000455a99
> RDX: 0000000000000048 RSI: 0000000020000240 RDI: 0000000000000005
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000005
> R13: 00000000004bb7d5 R14: 00000000004c8508 R15: 0000000000000023
> BUG: unable to handle kernel paging request at ffffffffa0008002
> PGD 8e6d067 P4D 8e6d067 PUD 8e6e063 PMD 1b4528067 PTE 1d433d161
> Oops: 0003 [#1] SMP KASAN
> CPU: 1 PID: 4811 Comm: syz-executor0 Not tainted 4.18.0-rc1+ #114
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
> 01/01/2011
> RIP: 0010:bpf_jit_binary_lock_ro include/linux/filter.h:703 [inline]
> RIP: 0010:bpf_int_jit_compile+0xc36/0xf30 arch/x86/net/bpf_jit_comp.c:1168

static inline void bpf_jit_binary_lock_ro(struct bpf_binary_header *hdr)
{
        WARN_ON_ONCE(set_memory_ro((unsigned long)hdr, hdr->pages));
}

Qualitee. set_memory_ro() has legitimate reasons to fail, but sure it does
not most of the time.

So instead of implementing proper error handling, this adds complete bogus
wrappers. Hell, set_memory_*() have stub functions which return 0 for the
CONFIG_ARCH_HAS_SET_MEMORY=n case.

The unlock function is even more hilarious:

static inline void bpf_prog_unlock_ro(struct bpf_prog *fp)
{
        if (fp->locked) {
                WARN_ON_ONCE(set_memory_rw((unsigned long)fp, fp->pages));
                /* In case set_memory_rw() fails, we want to be the first
                 * to crash here instead of some random place later on.
                 */
                fp->locked = 0;
        }
}

Great approach for a facility, which deals with untrusted user space
stuff. Yeah. I know. The BPF mantra is: "Performance first"

I'm really tempted to make the BPF config switch depend on BROKEN. 

Thanks,

	tglx