linux-kernel - Re: [syzbot] KMSAN: uninit-value in longest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAG_fn=Vz2sTxVAu1gfq6pYSvX0qsGpsWU8ap5kHW28oENNtBOg@mail.gmail.com>
Date:   Tue, 24 Jan 2023 12:07:23 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     syzbot <syzbot+14d9e7602ebdf7ec0a60@...kaller.appspotmail.com>,
        clm@...com, dsterba@...e.com, josef@...icpanda.com,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] KMSAN: uninit-value in longest_match

> > Can't we just pass __GFP_ZERO when allocating the workspace here:
> >
> > ...
> > This is what Chrome folks did in the same situation (
> > https://chromium.googlesource.com/chromium/src.git/+/962cbbe81708214ff8e14e2bc8a07271cb15f1b9
> > )
>
> Sure, the btrfs folks can do that if they want to avoid this warning for the
> btrfs zlib compression specifically.  This would not solve the issue for the
> other users of zlib compression in the kernel.

We probably can't fix zlib without sacrificing performance, so I think
the right thing to do is to actually modify the users of zlib
compression to pass only initialized data to zlib.
Doing so will make the calls to zlib_deflate() well-defined, whereas
marking longest_match() as buggy will just hide future error reports,
but won't fix the code in question.