[syzbot] [mm?] KMSAN: kernel-infoleak in bpf_probe_write_user

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: fec50db7033e Linux 6.9-rc3
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=16509ba1180000
kernel config: https://syzkaller.appspot.com/x/.config?x=13e7da432565d94c
dashboard link: https://syzkaller.appspot.com/bug?extid=79102ed905e5b2dc0fc3
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10a4af9d180000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12980f9d180000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/901017b36ccc/disk-fec50db7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/16bfcf5618d3/vmlinux-fec50db7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/dc9c5a1e7d02/bzImage-fec50db7.xz

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

=====================================================
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in __copy_to_user_inatomic include/linux/uaccess.h:125 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_nofault+0x129/0x1f0 mm/maccess.c:149
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
__copy_to_user_inatomic include/linux/uaccess.h:125 [inline]
copy_to_user_nofault+0x129/0x1f0 mm/maccess.c:149
____bpf_probe_write_user kernel/trace/bpf_trace.c:349 [inline]
bpf_probe_write_user+0x104/0x180 kernel/trace/bpf_trace.c:327
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
__bpf_prog_run64+0xb5/0xe0 kernel/bpf/core.c:2236
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
__bpf_prog_run include/linux/filter.h:657 [inline]
bpf_prog_run include/linux/filter.h:664 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2381 [inline]
bpf_trace_run2+0x116/0x300 kernel/trace/bpf_trace.c:2420
__bpf_trace_kfree+0x29/0x40 include/trace/events/kmem.h:94
trace_kfree include/trace/events/kmem.h:94 [inline]
kfree+0x6a5/0xa30 mm/slub.c:4377
vfs_writev+0x12bf/0x1450 fs/read_write.c:978
do_writev+0x251/0x5c0 fs/read_write.c:1018
__do_sys_writev fs/read_write.c:1091 [inline]
__se_sys_writev fs/read_write.c:1088 [inline]
__x64_sys_writev+0x98/0xe0 fs/read_write.c:1088
do_syscall_64+0xd5/0x1f0
entry_SYSCALL_64_after_hwframe+0x72/0x7a

Local variable stack created at:
__bpf_prog_run64+0x45/0xe0 kernel/bpf/core.c:2236
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
__bpf_prog_run include/linux/filter.h:657 [inline]
bpf_prog_run include/linux/filter.h:664 [inline]
__bpf_trace_run kernel/trace/bpf_trace.c:2381 [inline]
bpf_trace_run2+0x116/0x300 kernel/trace/bpf_trace.c:2420

Bytes 0-7 of 8 are uninitialized
Memory access of size 8 starts at ffff888121ec7ae8
Data copied to user address 00000000ffffffff

CPU: 1 PID: 4779 Comm: dhcpcd Not tainted 6.9.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
=====================================================


---
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.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Andrew Morton]

(cc bpf@)

[Alexei Starovoitov]

Hi,

syzbot folks, please disable such "bug" reporting.
The whole point of bpf is to pass such info to userspace.
probe_write_user, various ring buffers, bpf_*_printk-s, bpf maps
all serve this purpose of "infoleak".

[Aleksandr Nogikh]

(+Alexander Potapenko)

Hi Alexei,

Thanks for bringing this up!
I guess some annotations in the kernel code need to be adjusted.
Syzbot stress-tests the kernel, but in the end it's the kernel itself
that detects problems and prints error reports.

--
Aleksandr

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAADnVQ%2BE%3Dj1Z4MOuk2f-U33oqvUmmrRcvWvsDrmLXvD8FhUmsQ%40mail.gmail.com.

[Alexander Potapenko]

On Mon, Apr 15, 2024 at 11:06 PM Alexei Starovoitov
<alexei.st...@gmail.com> wrote:
>

> Hi,
>
> syzbot folks, please disable such "bug" reporting.
> The whole point of bpf is to pass such info to userspace.
> probe_write_user, various ring buffers, bpf_*_printk-s, bpf maps
> all serve this purpose of "infoleak".
>

Hi Alexei,

From KMSAN's perspective it is fine to pass information to the
userspace, unless it is marked as uninitialized.
It could be that we are missing some initialization in kernel/bpf/core.c though.
Do you know which part of the code is supposed to initialize the stack
in PROG_NAME?

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAADnVQ%2BE%3Dj1Z4MOuk2f-U33oqvUmmrRcvWvsDrmLXvD8FhUmsQ%40mail.gmail.com.

--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[Alexei Starovoitov]

On Tue, Apr 16, 2024 at 1:52 AM Alexander Potapenko <gli...@google.com> wrote:
>
> On Mon, Apr 15, 2024 at 11:06 PM Alexei Starovoitov
> <alexei.st...@gmail.com> wrote:
> >
> > Hi,
> >
> > syzbot folks, please disable such "bug" reporting.
> > The whole point of bpf is to pass such info to userspace.
> > probe_write_user, various ring buffers, bpf_*_printk-s, bpf maps
> > all serve this purpose of "infoleak".
> >
>
> Hi Alexei,
>
> From KMSAN's perspective it is fine to pass information to the
> userspace, unless it is marked as uninitialized.
> It could be that we are missing some initialization in kernel/bpf/core.c though.
> Do you know which part of the code is supposed to initialize the stack
> in PROG_NAME?

cap_bpf + cap_perfmon bpf program are allowed to read uninitialized stack.

And recently we added
commit e8742081db7d ("bpf: Mark bpf prog stack with
kmsan_unposion_memory in interpreter mode")
to shut up syzbot.

[Alexander Potapenko]

On Tue, Apr 16, 2024 at 5:16 PM Alexei Starovoitov

<alexei.st...@gmail.com> wrote:
>
> On Tue, Apr 16, 2024 at 1:52 AM Alexander Potapenko <gli...@google.com> wrote:
> >
> > On Mon, Apr 15, 2024 at 11:06 PM Alexei Starovoitov
> > <alexei.st...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > syzbot folks, please disable such "bug" reporting.
> > > The whole point of bpf is to pass such info to userspace.
> > > probe_write_user, various ring buffers, bpf_*_printk-s, bpf maps
> > > all serve this purpose of "infoleak".
> > >
> >
> > Hi Alexei,
> >
> > From KMSAN's perspective it is fine to pass information to the
> > userspace, unless it is marked as uninitialized.
> > It could be that we are missing some initialization in kernel/bpf/core.c though.
> > Do you know which part of the code is supposed to initialize the stack
> > in PROG_NAME?
>
> cap_bpf + cap_perfmon bpf program are allowed to read uninitialized stack.

Out of curiosity, is this feature supposed to be used in production kernels?

> And recently we added
> commit e8742081db7d ("bpf: Mark bpf prog stack with
> kmsan_unposion_memory in interpreter mode")
> to shut up syzbot.

I checked that the report in question is not reproducible with this
patch anymore. Let's just wait until it reaches the mainline.