Re: [syzbot] KASAN: vmalloc-out-of-bounds Read in bpf_jit_free

[Song Liu]

On Mon, Feb 14, 2022 at 3:52 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> Song, ptal.
>
> On 2/14/22 7:45 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    e5313968c41b Merge branch 'Split bpf_sk_lookup remote_port..
> > git tree:       bpf-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10baced8700000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=c40b67275bfe2a58
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+2f649ec6d2eea1495a8f@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > ==================================================================
> > BUG: KASAN: vmalloc-out-of-bounds in bpf_jit_binary_pack_free kernel/bpf/core.c:1120 [inline]
> > BUG: KASAN: vmalloc-out-of-bounds in bpf_jit_free+0x2b5/0x2e0 kernel/bpf/core.c:1151
> > Read of size 4 at addr ffffffffa0001a80 by task kworker/0:18/13642
> >
> > CPU: 0 PID: 13642 Comm: kworker/0:18 Not tainted 5.16.0-syzkaller-11655-ge5313968c41b #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Workqueue: events bpf_prog_free_deferred
> > Call Trace:
> >   <TASK>
> >   __dump_stack lib/dump_stack.c:88 [inline]
> >   dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> >   print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255
> >   __kasan_report mm/kasan/report.c:442 [inline]
> >   kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
> >   bpf_jit_binary_pack_free kernel/bpf/core.c:1120 [inline]
> >   bpf_jit_free+0x2b5/0x2e0 kernel/bpf/core.c:1151
> >   bpf_prog_free_deferred+0x5c1/0x790 kernel/bpf/core.c:2524
> >   process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307
> >   worker_thread+0x657/0x1110 kernel/workqueue.c:2454
> >   kthread+0x2e9/0x3a0 kernel/kthread.c:377
> >   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
> >   </TASK>

I think this is the same issue as [1], that the 2MB page somehow got freed
while still in use. I couldn't spot any bug with bpf_prog_pack allocate/free
logic. I haven't got luck reproducing it either. Will continue tomorrow.


[1] https://lore.kernel.org/netdev/0000000000007646bd05d7f81943@xxxxxxxxxx/t/

> >
> >
> > Memory state around the buggy address:
> >   ffffffffa0001980: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >   ffffffffa0001a00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >> ffffffffa0001a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >                     ^
> >   ffffffffa0001b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >   ffffffffa0001b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ==================================================================
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@xxxxxxxxxxxxxxxx.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> >
>