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

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: ce83278f313c Merge branch 'qed-enhancements'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11c8ce3ab00000
kernel config: https://syzkaller.appspot.com/x/.config?x=b5949d4891208a1b
dashboard link: https://syzkaller.appspot.com/bug?extid=5027de09e0964fd78ce1
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+5027de...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put.constprop.0+0x1dd/0x220 kernel/bpf/syscall.c:1812
Read of size 8 at addr ffffc90000cf2038 by task kworker/0:24/16179

CPU: 0 PID: 16179 Comm: kworker/0:24 Not tainted 5.16.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events sk_psock_destroy
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/0x320 mm/kasan/report.c:247
__kasan_report mm/kasan/report.c:433 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
__bpf_prog_put.constprop.0+0x1dd/0x220 kernel/bpf/syscall.c:1812
psock_set_prog include/linux/skmsg.h:477 [inline]
psock_progs_drop include/linux/skmsg.h:495 [inline]
sk_psock_destroy+0xad/0x620 net/core/skmsg.c:804
process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
kthread+0x405/0x4f0 kernel/kthread.c:327
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>


Memory state around the buggy address:
ffffc90000cf1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90000cf1f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90000cf2000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90000cf2080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90000cf2100: 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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[John Fastabend]

I'll take look some psock issue here.

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 1c5526968e27 net/smc: Clear memory when release and reuse ..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13a9eabdb00000
kernel config: https://syzkaller.appspot.com/x/.config?x=2b8e24e3a80e3875

dashboard link: https://syzkaller.appspot.com/bug?extid=5027de09e0964fd78ce1
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12b749a9b00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=170d7519b00000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5027de...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_put.constprop.0+0x1dd/0x220 kernel/bpf/syscall.c:1812

Read of size 8 at addr ffffc90001a16038 by task kworker/0:3/2934

CPU: 0 PID: 2934 Comm: kworker/0:3 Not tainted 5.16.0-rc3-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events sk_psock_destroy
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/0x320 mm/kasan/report.c:247
__kasan_report mm/kasan/report.c:433 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
__bpf_prog_put.constprop.0+0x1dd/0x220 kernel/bpf/syscall.c:1812
psock_set_prog include/linux/skmsg.h:477 [inline]
psock_progs_drop include/linux/skmsg.h:495 [inline]
sk_psock_destroy+0xad/0x620 net/core/skmsg.c:804
process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
kthread+0x405/0x4f0 kernel/kthread.c:327
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
</TASK>


Memory state around the buggy address:

ffffc90001a15f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90001a15f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90001a16000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90001a16080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90001a16100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 218d747a4142f281a256687bb513a135c905867b
Author: John Fastabend <john.fa...@gmail.com>
Date: Tue Jan 4 21:46:45 2022 +0000

bpf, sockmap: Fix double bpf_prog_put on error case in map_link

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12919c37b00000
start commit: 662f11d55ffd docs: networking: dpaa2: Fix DPNI header
git tree: net
kernel config: https://syzkaller.appspot.com/x/.config?x=fa556098924b78f0
dashboard link: https://syzkaller.appspot.com/bug?extid=5027de09e0964fd78ce1
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14fccadbb00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1598d9ebb00000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: bpf, sockmap: Fix double bpf_prog_put on error case in map_link

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Vegard Nossum]

On Thu, 20 Jan 2022 at 15:17, syzbot
<syzbot+5027de...@syzkaller.appspotmail.com> wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 218d747a4142f281a256687bb513a135c905867b
> Author: John Fastabend <john.fa...@gmail.com>
> Date: Tue Jan 4 21:46:45 2022 +0000
>
> bpf, sockmap: Fix double bpf_prog_put on error case in map_link

I can confirm the above commit fixes the issue, but it references a
slightly different report. Looks like the only difference is
__bpf_prog_put instead of bpf_prog_put:

KASAN: vmalloc-out-of-bounds Read in __bpf_prog_put
KASAN: vmalloc-out-of-bounds Read in bpf_prog_put

However, looking at the stack traces for the two bugs shows that
__bpf_prog_put() is really the location for both reports, see:

https://syzkaller.appspot.com/bug?id=797cd651dd0d9bd921e4fa51b792f5afdc3f390f
kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 mm/kasan/report.c:450
__bpf_prog_put.constprop.0+0x1dd/0x220 kernel/bpf/syscall.c:1812
kernel/bpf/syscall.c:1812
bpf_prog_put kernel/bpf/syscall.c:1829 [inline]
bpf_prog_put kernel/bpf/syscall.c:1829 [inline] kernel/bpf/syscall.c:1837

vs.

https://syzkaller.appspot.com/bug?extid=bb73e71cf4b8fd376a4f
kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450
__bpf_prog_put kernel/bpf/syscall.c:1812 [inline]
__bpf_prog_put kernel/bpf/syscall.c:1812 [inline] kernel/bpf/syscall.c:1829
bpf_prog_put+0x8c/0x4f0 kernel/bpf/syscall.c:1829 kernel/bpf/syscall.c:1829

Looks to me like the compiler's inlining decision caused syzbot to see
__bpf_prog_put() instead of bpf_prog_put(), but I can't tell if it's
because it got inlined or because of the .constprop.0 suffix... I
guess syzbot skips the [inline] entries when deciding which function
to report the bug in?

In any case:

#syz dup: KASAN: vmalloc-out-of-bounds Read in bpf_prog_put


Vegard

[Dmitry Vyukov]

Not sure if you are still interested in this or not...
But, yes, it's inline frames that are a problem, ".constprop.0" should
be stripped.
syzkaller parses non-symbolized kernel output w/o inlined frames to
extract the title. This was a very early decision, not sure if it's
the right one or not. On the other hand using inline frames can cause
attribution to all the common one-liners.
Now it's somewhat hard to change b/c if we change it, new crashes will
be parsed differently and it will cause a storm of duplicates for
already reported bugs.