Received-SPF: pass (google.com: domain of linux-kernel+bounces-149683-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <000000000000fe696d0615f120bb@google.com> <20240415131837.411c6e05eb7b0af077d6424a@linux-foundation.org>
 <CAADnVQ+E=j1Z4MOuk2f-U33oqvUmmrRcvWvsDrmLXvD8FhUmsQ@mail.gmail.com>
 <CAG_fn=Uxaq1juuq-3cA1qQu6gB7ZB=LpyxBEdKf7DpYfAo3zmg@mail.gmail.com> <CAADnVQLUXVV_viC7mmm6VaAyveQKMzibdCMpnUQdf_-3FdjM7Q@mail.gmail.com>
In-Reply-To: <CAADnVQLUXVV_viC7mmm6VaAyveQKMzibdCMpnUQdf_-3FdjM7Q@mail.gmail.com>
From: Alexander Potapenko <glider@google.com>
Date: Thu, 18 Apr 2024 09:58:48 +0200
Message-ID: <CAG_fn=X-etq6NQOo70tDJb9m8RZ8z67E1imSqn-Pq1nYV7Ub_g@mail.gmail.com>
Subject: Re: [syzbot] [mm?] KMSAN: kernel-infoleak in bpf_probe_write_user
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, 
	syzbot <syzbot+79102ed905e5b2dc0fc3@syzkaller.appspotmail.com>, 
	LKML <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, 
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>, bpf <bpf@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 16, 2024 at 5:16=E2=80=AFPM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Apr 16, 2024 at 1:52=E2=80=AFAM Alexander Potapenko <glider@googl=
e.com> wrote:
> >
> > On Mon, Apr 15, 2024 at 11:06=E2=80=AFPM 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.