Re: BUG: unable to handle kernel paging request in bpf_int_jit_compile
From: Thomas Gleixner <hidden>
Date: 2018-06-24 07:09:38
Also in:
lkml
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@syzkaller.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