[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG_fn=X-etq6NQOo70tDJb9m8RZ8z67E1imSqn-Pq1nYV7Ub_g@mail.gmail.com>
Date: Thu, 18 Apr 2024 09:58:48 +0200
From: Alexander Potapenko <glider@...gle.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
syzbot <syzbot+79102ed905e5b2dc0fc3@...kaller.appspotmail.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>, bpf <bpf@...r.kernel.org>
Subject: Re: [syzbot] [mm?] KMSAN: kernel-infoleak in bpf_probe_write_user
On Tue, Apr 16, 2024 at 5:16 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Tue, Apr 16, 2024 at 1:52 AM Alexander Potapenko <glider@...gle.com> wrote:
> >
> > On Mon, Apr 15, 2024 at 11:06 PM Alexei Starovoitov
> > <alexei.starovoitov@...il.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.
Powered by blists - more mailing lists