MIME-Version: 1.0
References: <0000000000004f995905ef61a764@google.com> <Y5geWpk1WfgwjzuA@sol.localdomain>
 <CAG_fn=XDN23qMwwMCPi=8drv9kE6Z-goFQ8nNN8Qux3bdrnvLw@mail.gmail.com> <Y5o9lHS04s9QTRNH@sol.localdomain>
In-Reply-To: <Y5o9lHS04s9QTRNH@sol.localdomain>
From:   Alexander Potapenko <glider@google.com>
Date:   Tue, 24 Jan 2023 12:07:23 +0100
Message-ID: <CAG_fn=Vz2sTxVAu1gfq6pYSvX0qsGpsWU8ap5kHW28oENNtBOg@mail.gmail.com>
Subject: Re: [syzbot] KMSAN: uninit-value in longest_match
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     syzbot <syzbot+14d9e7602ebdf7ec0a60@syzkaller.appspotmail.com>,
        clm@fb.com, dsterba@suse.com, josef@toxicpanda.com,
        linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> > 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.