Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <0000000000008a7ae505aef61db1@google.com> <20200911170150.GA889@sol.localdomain>
 <c16e9ab9-13e0-b911-e33a-c9ae81e93a8d@I-love.SAKURA.ne.jp>
 <CAMj1kXFqYozjJ+qPeSApESb0Cb6CUaGXBrs5LP81ERRvb3+TAw@mail.gmail.com>
 <59e1d5c0-aedb-7b5b-f37f-0c20185d7e9b@I-love.SAKURA.ne.jp>
 <CAMj1kXGHRUUFYL09Lm-mO6MfGc19rC=-7mSJ1eDTcbw7QuEkaw@mail.gmail.com>
 <CAG_fn=X+eU=-WLXASidBCHWS3L7RvtN=mx3Bj8GD9GcA=Htf2w@mail.gmail.com>
 <CAMj1kXFrsc7bsjo2i0=9AqVNSCvXEnYAukzoXeaYEH9EpNviBA@mail.gmail.com> <CAG_fn=VFa2yeiZmdyuVRmZYtWn6Tkox8UVrOrCv4tEec3BFYbQ@mail.gmail.com>
In-Reply-To: <CAG_fn=VFa2yeiZmdyuVRmZYtWn6Tkox8UVrOrCv4tEec3BFYbQ@mail.gmail.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 30 Jun 2023 13:49:34 +0200
Message-ID: <CAMj1kXEdwjN7Q8tKVxHz98zQ4EsWVSdLZ5tQaV-nXxc9hwRYjQ@mail.gmail.com>
Subject: Re: [PATCH] net: tls: enable __GFP_ZERO upon tls_init()
To:     Alexander Potapenko <glider@google.com>
Cc:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Boris Pismenny <borisp@nvidia.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>, herbert@gondor.apana.org.au,
        linux-crypto@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+828dfc12440b4f6f305d@syzkaller.appspotmail.com>,
        Eric Biggers <ebiggers@kernel.org>,
        Aviad Yehezkel <aviadye@nvidia.com>,
        Daniel Borkmann <daniel@iogearbox.net>, netdev@vger.kernel.org,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 30 Jun 2023 at 13:38, Alexander Potapenko <glider@google.com> wrote=
:
>
> On Fri, Jun 30, 2023 at 12:18=E2=80=AFPM Ard Biesheuvel <ardb@kernel.org>=
 wrote:
> >
> > On Fri, 30 Jun 2023 at 12:11, Alexander Potapenko <glider@google.com> w=
rote:
> > >
> > > On Fri, Jun 30, 2023 at 12:02=E2=80=AFPM Ard Biesheuvel <ardb@kernel.=
org> wrote:
> > > >
> > > > On Fri, 30 Jun 2023 at 11:53, Tetsuo Handa
> > > > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > > > >
> > > > > On 2023/06/30 18:36, Ard Biesheuvel wrote:
> > > > > > Why are you sending this now?
> > > > >
> > > > > Just because this is currently top crasher and I can reproduce lo=
cally.
> > > > >
> > > > > > Do you have a reproducer for this issue?
> > > > >
> > > > > Yes. https://syzkaller.appspot.com/text?tag=3DReproC&x=3D12931621=
900000 works.
> > > > >
> > > >
> > > > Could you please share your kernel config and the resulting kernel =
log
> > > > when running the reproducer? I'll try to reproduce locally as well,
> > > > and see if I can figure out what is going on in the crypto layer
> > >
> > > The config together with the repro is available at
> > > https://syzkaller.appspot.com/bug?extid=3D828dfc12440b4f6f305d, see t=
he
> > > latest row of the "Crashes" table that contains a C repro.
> >
> > Could you explain why that bug contains ~50 reports that seem entirely
> > unrelated?
>
> These are some unfortunate effects of syzbot trying to deduplicate
> bugs. There's a tradeoff between reporting every single crash
> separately and grouping together those that have e.g. the same origin.
> Applying this algorithm transitively results in bigger clusters
> containing unwanted reports.
> We'll look closer.
>
> > AIUI, this actual issue has not been reproduced since
> > 2020??
>
> Oh, sorry, I misread the table and misinformed you. The topmost row of
> the table is indeed the _oldest_ one.
> Another manifestation of the bug was on 2023/05/23
> (https://syzkaller.appspot.com/text?tag=3DCrashReport&x=3D146f66b1280000)
>

That one has nothing to do with networking, so I don't see how this
patch would affect it.

>
> >
> > > Config: https://syzkaller.appspot.com/text?tag=3DKernelConfig&x=3Dee5=
f7a0b2e48ed66
> > > Report: https://syzkaller.appspot.com/text?tag=3DCrashReport&x=3D1325=
260d900000
> > > Syz repro: https://syzkaller.appspot.com/text?tag=3DReproSyz&x=3D11af=
973e900000
> > > C repro: https://syzkaller.appspot.com/text?tag=3DReproC&x=3D163a1e45=
900000
> > >
> > > The bug is reproducible for me locally as well (and Tetsuo's patch
> > > makes it disappear, although I have no opinion on its correctness).
> >
> > What I'd like to do is run a kernel plus initrd locally in OVMF and
> > reproduce the issue - can I do that without all the syzkaller
> > machinery?
>
> You can build the kernel from the config linked above, that's what I
> did to reproduce it locally.
> As for initrd, there are disk images attached to the reports, will that h=
elp?
>
> E.g.
>   $ wget https://storage.googleapis.com/syzbot-assets/79bb4ff7cc58/disk-f=
93f2fed.raw.xz
>   $ unxz disk-f93f2fed.raw.xz
>   $ qemu-system-x86_64 -smp 2,sockets=3D2,cores=3D1 -m 4G -drive
> file=3Ddisk-f93f2fed.raw -snapshot -nographic -enable-kvm
>
> lets me boot syzkaller with the disk/kernel from that report of 2023/05/2=
3.
> Adding "-net user,hostfwd=3Dtcp::10022-:22 -net nic,model=3De1000" I am
> also able to SSH into the machine (there's no password):
>
> $ ssh -o "StrictHostKeyChecking no"  -p 10022     root@localhost
>
> Then the repro can be downloaded and executed:
>
> $ wget "https://syzkaller.appspot.com/text?tag=3DReproC&x=3D163a1e4590000=
0" -O t.c
> $ gcc t.c -static -o t
> $ scp -o "StrictHostKeyChecking no" -P 10022   t  root@localhost:
> $ ssh -o "StrictHostKeyChecking no"  -p 10022     root@localhost ./t
>
> Within a couple minutes the kernel crashes with the report:
>
> [  151.522472][ T5865] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> [  151.523843][ T5865] BUG: KMSAN: uninit-value in aes_encrypt+0x15cc/0x1=
db0
> [  151.525120][ T5865]  aes_encrypt+0x15cc/0x1db0
> [  151.526113][ T5865]  aesti_encrypt+0x7d/0xf0
> [  151.527057][ T5865]  crypto_cipher_encrypt_one+0x112/0x200
> [  151.528224][ T5865]  crypto_cbcmac_digest_update+0x301/0x4b0
>

OK, thanks for the instructions.

Out of curiosity - does the stack trace you cut off here include the
BPF routine mentioned in the report?