[FFmpeg-devel] [OSS-Fuzz] Have you considered enabling memory sanitizer?

[Kacper Michajlow]

On Sun, 14 Jul 2024 at 21:55, Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote:
> > On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow <kasper93 at gmail.com> wrote:
> > >
> > > On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer
> > > <michael at niedermayer.cc> wrote:
> > > >
> > > > On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote:
> > > > > Hi,
> > > > >
> > > > > Like in the topic. I think it would be useful to enable MSAN on
> > > > > OSS-Fuzz. We get some tiny issues and it would be probably good to
> > > > > have them tracked upstream. All infra is here, so enabling it is as
> > > > > simple as adding it to the project.yaml. Except libbz2.so and libz.so
> > > > > would have to be built inline instead, looking at the build.sh, they
> > > > > are prebuilt. The rest should just work (TM), but needs to be tested.
> > > > > You can set an "experimental' flag to have it not create issues on
> > > > > monorail, initially.
> > > >
> > > > I assumed ossfuzz would enable all sanitizers by default
> > >
> > > They do not do that by default, because MSAN requires all dependencies
> > > to be instrumented too. See
> > > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers
> > >
> > > Looking at build.sh for ffmpeg, it should be fine to enable it.
> > > Obviously I have not tested everything, but I was running some tests
> > > locally with MSAN and also tested it with mpv oss-fuzz builds where we
> > > build ffmpeg too with MSAN.
> > >
> > > - Kacper
> >
> > I've sent a PR to enable MSAN and a few other build improvements.
> > Please take a look https://github.com/google/oss-fuzz/pull/12211
> >
>
> > Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to
> > monitor what issues are reported upstream, as we get some reports in
> > mpv fuzzing and I never know if I should report it upstream (ffmpeg)
> > or it is already found by first-party fuzzing and I shouldn't make
> > more noise.
>
> you are welcome to submit bug reports, you are welcome to submit bug fixes
> if you find issues in FFmpeg.
>
> If someones work in FFmpeg or rather FFmpeg benefits from someone having
> access to the reports, then (s)he should receive access. This seems not
> to apply here

I respect your decision. However, saying that anyone's (or my)
contribution doesn't benefit FFmpeg is a strange thing to say for an
open source project maintainer.

It's all about time. I don't get paid to do any of this, so
duplicating issues/reports manually from one system to another, if
they are already reported, is a monkey's job which I'm not willing to
do. This time could be devoted to actually fixing the issues. I'd like
to help, but if it is not required, I will focus on other things.

It also doesn't help that trac.ffmpeg is a black hole, where only
Balling seems to be reading those tickets. Frankly, the review process
is not better, as even trivial fixes take months to merge.

> Also i expect the number of outstanding ossfuzz issues to decrease now
> after the bulk of coverity issues has been dealt with

For some class of issues sure, but Coverity bigfixes are most of the
time workarounding the static analysis limitations. Fuzzing is more
powerful and analyzes the code as a whole, not small snippets of it.

- Kacper