Re: [PATCH] net: tls: enable __GFP_ZERO upon tls_init()

From: Ard Biesheuvel <ardb@kernel.org>
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>
Subject: Re: [PATCH] net: tls: enable __GFP_ZERO upon tls_init()
Date: Fri, 30 Jun 2023 13:49:34 +0200	[thread overview]
Message-ID: <CAMj1kXEdwjN7Q8tKVxHz98zQ4EsWVSdLZ5tQaV-nXxc9hwRYjQ@mail.gmail.com> (raw)
In-Reply-To: <CAG_fn=VFa2yeiZmdyuVRmZYtWn6Tkox8UVrOrCv4tEec3BFYbQ@mail.gmail.com>

On Fri, 30 Jun 2023 at 13:38, Alexander Potapenko <glider@google.com> wrote:
>
> On Fri, Jun 30, 2023 at 12:18 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Fri, 30 Jun 2023 at 12:11, Alexander Potapenko <glider@google.com> wrote:
> > >
> > > On Fri, Jun 30, 2023 at 12:02 PM 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 locally.
> > > > >
> > > > > > Do you have a reproducer for this issue?
> > > > >
> > > > > Yes. https://syzkaller.appspot.com/text?tag=ReproC&x=12931621900000 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=828dfc12440b4f6f305d, see the
> > > 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=CrashReport&x=146f66b1280000)
>

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=KernelConfig&x=ee5f7a0b2e48ed66
> > > Report: https://syzkaller.appspot.com/text?tag=CrashReport&x=1325260d900000
> > > Syz repro: https://syzkaller.appspot.com/text?tag=ReproSyz&x=11af973e900000
> > > C repro: https://syzkaller.appspot.com/text?tag=ReproC&x=163a1e45900000
> > >
> > > 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 help?
>
> E.g.
>   $ wget https://storage.googleapis.com/syzbot-assets/79bb4ff7cc58/disk-f93f2fed.raw.xz
>   $ unxz disk-f93f2fed.raw.xz
>   $ qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive
> file=disk-f93f2fed.raw -snapshot -nographic -enable-kvm
>
> lets me boot syzkaller with the disk/kernel from that report of 2023/05/23.
> Adding "-net user,hostfwd=tcp::10022-:22 -net nic,model=e1000" 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=ReproC&x=163a1e45900000" -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] =====================================================
> [  151.523843][ T5865] BUG: KMSAN: uninit-value in aes_encrypt+0x15cc/0x1db0
> [  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?