lkml.org 
[lkml]   [2024]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [syzbot] [mm?] KMSAN: kernel-infoleak in bpf_probe_write_user
On Tue, Apr 16, 2024 at 5:16 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Apr 16, 2024 at 1:52 AM Alexander Potapenko <glider@google.com> wrote:
> >
> > On Mon, Apr 15, 2024 at 11:06 PM Alexei Starovoitov
> > <alexei.starovoitov@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.

\
 
 \ /
  Last update: 2024-04-18 09:59    [W:0.075 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site