[FFmpeg-devel] [PATCH 1/6] avformat/segafilm: Set keyframe

[FFmpeg-devel] [PATCH 1/6] avformat/segafilm: Set keyframe

[Michael Niedermayer]

Fixes: use of uninitialized value
Fixes: 70871/clusterfuzz-testcase-minimized-ffmpeg_dem_SEGAFILM_fuzzer-5883617752973312

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/segafilm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
index 96a50c0e3b3..e72d872f963 100644
--- a/libavformat/segafilm.c
+++ b/libavformat/segafilm.c
@@ -234,6 +234,7 @@ static int film_read_header(AVFormatContext *s)
             else if (film->audio_type != AV_CODEC_ID_NONE)
                 audio_frame_counter += (film->sample_table[i].sample_size /
                     (film->audio_channels * film->audio_bits / 8));
+            film->sample_table[i].keyframe = 1;
         } else {
             film->sample_table[i].stream = film->video_stream_index;
             film->sample_table[i].pts = AV_RB32(&scratch[8]) & 0x7FFFFFFF;
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/6] avformat/av1dec: Check bits left before get_leb128()

[Michael Niedermayer]

Fixes: use of uninitialized value
Fixes: 70872/clusterfuzz-testcase-minimized-ffmpeg_dem_OBU_fuzzer-6005782487826432

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/av1dec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/av1dec.c b/libavformat/av1dec.c
index 3363003b181..a5b620a0abf 100644
--- a/libavformat/av1dec.c
+++ b/libavformat/av1dec.c
@@ -326,6 +326,9 @@ static int read_obu_with_size(const uint8_t *buf, int buf_size, int64_t *obu_siz
         skip_bits(&gb, 3);  // extension_header_reserved_3bits
     }
 
+    if (get_bits_left(&gb) < 8)
+        return AVERROR_INVALIDDATA;
+
     *obu_size  = get_leb128(&gb);
     if (*obu_size > INT_MAX)
         return AVERROR_INVALIDDATA;
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/6] avformat/iamfdec: Check nb_layers before dereferencing layer

[Michael Niedermayer]

Fixes: dereferencing pointers near NULL
Fixes: 70432/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5255672845893632
Fixes: 70877/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5348547432611840

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/iamfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/iamfdec.c b/libavformat/iamfdec.c
index ce6d4aa0647..2e6608b8685 100644
--- a/libavformat/iamfdec.c
+++ b/libavformat/iamfdec.c
@@ -107,7 +107,7 @@ static int iamf_read_header(AVFormatContext *s)
             if (ret < 0)
                 return ret;
 
-            if (!i && !j && audio_element->layers[0].substream_count == 1)
+            if (!i && !j && audio_element->nb_layers && audio_element->layers[0].substream_count == 1)
                 st->disposition |= AV_DISPOSITION_DEFAULT;
             else
                 st->disposition |= AV_DISPOSITION_DEPENDENT;
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/6] avformat/wtvdec: clear sectors

[Michael Niedermayer]

The code can leave uninitialized holes in the array.
Fixes: use of uninitialized values
Fixes: 70883/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6698694567591936

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/wtvdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index e153034aa19..1a6c4c33481 100644
--- a/libavformat/wtvdec.c
+++ b/libavformat/wtvdec.c
@@ -185,7 +185,7 @@ static AVIOContext * wtvfile_open_sector(unsigned first_sector, uint64_t length,
         int nb_sectors1 = read_ints(s->pb, sectors1, WTV_SECTOR_SIZE / 4);
         int i;
 
-        wf->sectors = av_malloc_array(nb_sectors1, 1 << WTV_SECTOR_BITS);
+        wf->sectors = av_calloc(nb_sectors1, 1 << WTV_SECTOR_BITS);
         if (!wf->sectors) {
             av_free(wf);
             return NULL;
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] avformat/wtvdec: clear sectors

[Peter Ross]

[-- Attachment #1.1: Type: text/plain, Size: 1209 bytes --]

On Wed, Aug 07, 2024 at 12:18:51AM +0200, Michael Niedermayer wrote:
> The code can leave uninitialized holes in the array.
> Fixes: use of uninitialized values
> Fixes: 70883/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6698694567591936
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavformat/wtvdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index e153034aa19..1a6c4c33481 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -185,7 +185,7 @@ static AVIOContext * wtvfile_open_sector(unsigned first_sector, uint64_t length,
>          int nb_sectors1 = read_ints(s->pb, sectors1, WTV_SECTOR_SIZE / 4);
>          int i;
>  
> -        wf->sectors = av_malloc_array(nb_sectors1, 1 << WTV_SECTOR_BITS);
> +        wf->sectors = av_calloc(nb_sectors1, 1 << WTV_SECTOR_BITS);
>          if (!wf->sectors) {
>              av_free(wf);
>              return NULL;

agree, please apply

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] avformat/wtvdec: clear sectors

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1420 bytes --]

On Wed, Aug 07, 2024 at 10:01:27AM +1000, Peter Ross wrote:
> On Wed, Aug 07, 2024 at 12:18:51AM +0200, Michael Niedermayer wrote:
> > The code can leave uninitialized holes in the array.
> > Fixes: use of uninitialized values
> > Fixes: 70883/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6698694567591936
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavformat/wtvdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> > index e153034aa19..1a6c4c33481 100644
> > --- a/libavformat/wtvdec.c
> > +++ b/libavformat/wtvdec.c
> > @@ -185,7 +185,7 @@ static AVIOContext * wtvfile_open_sector(unsigned first_sector, uint64_t length,
> >          int nb_sectors1 = read_ints(s->pb, sectors1, WTV_SECTOR_SIZE / 4);
> >          int i;
> >  
> > -        wf->sectors = av_malloc_array(nb_sectors1, 1 << WTV_SECTOR_BITS);
> > +        wf->sectors = av_calloc(nb_sectors1, 1 << WTV_SECTOR_BITS);
> >          if (!wf->sectors) {
> >              av_free(wf);
> >              return NULL;
> 
> agree, please apply

will apply

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

Fixes: use of uninitialized values
Fixes: 70885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6F_fuzzer-4610946029387776 (and likely others)

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 tools/target_dec_fuzzer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index d2d7e21dac7..794b5b92cc7 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -129,7 +129,7 @@ static int fuzz_video_get_buffer(AVCodecContext *ctx, AVFrame *frame)
 
     frame->extended_data = frame->data;
     for (i = 0; i < 4 && size[i]; i++) {
-        frame->buf[i] = av_buffer_alloc(size[i]);
+        frame->buf[i] = av_buffer_allocz(size[i]);
         if (!frame->buf[i])
             goto fail;
         frame->data[i] = frame->buf[i]->data;
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 729 bytes --]

On Wed, Aug 07, 2024 at 12:18:52AM +0200, Michael Niedermayer wrote:
> Fixes: use of uninitialized values
> Fixes: 70885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6F_fuzzer-4610946029387776 (and likely others)
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  tools/target_dec_fuzzer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[James Almer]

On 8/6/2024 7:18 PM, Michael Niedermayer wrote:
> Fixes: use of uninitialized values
> Fixes: 70885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6F_fuzzer-4610946029387776 (and likely others)
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   tools/target_dec_fuzzer.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> index d2d7e21dac7..794b5b92cc7 100644
> --- a/tools/target_dec_fuzzer.c
> +++ b/tools/target_dec_fuzzer.c
> @@ -129,7 +129,7 @@ static int fuzz_video_get_buffer(AVCodecContext *ctx, AVFrame *frame)
>   
>       frame->extended_data = frame->data;
>       for (i = 0; i < 4 && size[i]; i++) {
> -        frame->buf[i] = av_buffer_alloc(size[i]);
> +        frame->buf[i] = av_buffer_allocz(size[i]);
>           if (!frame->buf[i])
>               goto fail;
>           frame->data[i] = frame->buf[i]->data;

Wouldn't this hide actual decoder bugs too?

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3328 bytes --]

On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
> On 8/6/2024 7:18 PM, Michael Niedermayer wrote:
> > Fixes: use of uninitialized values
> > Fixes: 70885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6F_fuzzer-4610946029387776 (and likely others)
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   tools/target_dec_fuzzer.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> > index d2d7e21dac7..794b5b92cc7 100644
> > --- a/tools/target_dec_fuzzer.c
> > +++ b/tools/target_dec_fuzzer.c
> > @@ -129,7 +129,7 @@ static int fuzz_video_get_buffer(AVCodecContext *ctx, AVFrame *frame)
> >       frame->extended_data = frame->data;
> >       for (i = 0; i < 4 && size[i]; i++) {
> > -        frame->buf[i] = av_buffer_alloc(size[i]);
> > +        frame->buf[i] = av_buffer_allocz(size[i]);
> >           if (!frame->buf[i])
> >               goto fail;
> >           frame->data[i] = frame->buf[i]->data;
> 
> Wouldn't this hide actual decoder bugs too?

iam not sure i understand what you mean

If decoders are fed with uninitialized buffers thats a
security issue because there are thousands if not ten thousands of
pathes if you consider the number of decoders and the number
of ways they can hit errors
Pathes in which these buffers are not filled completely, so each
of these pathes would then need to clear the right bits of data.
Basically that means implementing error concealment for every decoder.
AND making sure that error concealment code is 100% bugfree and leaves
never a spot uncleaned and never touched something that was not writen to
Security wise this is not possible for production code, its too
fragile (at least with the number of decoders and active maintainers we have)
(you want less code to have to be bugfree for security not more code having
 to be bug free)

Now this is the fuzzer and not production code, ok. And of course is
great to have error concealment in every decoder
But then this leaves the question, who will do this work?
If noone does it then we will accumulate many msan bugs in ossfuzz that we wont
be able to do much with except ignore them.
This would make the fuzzer less efficient and it would confuse people looking
at the issues

Or the short punchy reply maybe is
Produce a volunteer who will fix these bugs before declaring them bugs.
And when doing so consider that we have bugfixes on the mailing list for which we
seem to not even have the man power to review and apply them

so yeah my oppinion is the default should be the simple & easy to maintain way.
If someone declares their decoder to have flawless error concealment (and for some
simple decoders that could be quite simple) these can always be excluded and use
uninitialized buffers in the fuzzer

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Kacper Michajlow]

On Fri, 9 Aug 2024 at 00:06, Michael Niedermayer <michael@niedermayer.cc> wrote:
>
> On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
> > On 8/6/2024 7:18 PM, Michael Niedermayer wrote:
> > > Fixes: use of uninitialized values
> > > Fixes: 70885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP6F_fuzzer-4610946029387776 (and likely others)
> > >
> > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > ---
> > >   tools/target_dec_fuzzer.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> > > index d2d7e21dac7..794b5b92cc7 100644
> > > --- a/tools/target_dec_fuzzer.c
> > > +++ b/tools/target_dec_fuzzer.c
> > > @@ -129,7 +129,7 @@ static int fuzz_video_get_buffer(AVCodecContext *ctx, AVFrame *frame)
> > >       frame->extended_data = frame->data;
> > >       for (i = 0; i < 4 && size[i]; i++) {
> > > -        frame->buf[i] = av_buffer_alloc(size[i]);
> > > +        frame->buf[i] = av_buffer_allocz(size[i]);
> > >           if (!frame->buf[i])
> > >               goto fail;
> > >           frame->data[i] = frame->buf[i]->data;
> >
> > Wouldn't this hide actual decoder bugs too?
>
> iam not sure i understand what you mean

In general, clearing buffers before processing makes MSAN less
effective in discovering invalid accesses because they would all
appear valid from its point of view. So, I guess the argument was that
this could hide actual decoder bugs since the buffers are already
initialized by the fuzzing binary itself, which, in theory, is
supposed to emulate the worst-case scenario for a tested decoder.

> If decoders are fed with uninitialized buffers thats a
> security issue because there are thousands if not ten thousands of
> pathes if you consider the number of decoders and the number
> of ways they can hit errors

Clearing those buffers in fuzzers does not alleviate this security
issue, as they may still be uninitialized in production code.

> Pathes in which these buffers are not filled completely, so each
> of these pathes would then need to clear the right bits of data.
> Basically that means implementing error concealment for every decoder.
> AND making sure that error concealment code is 100% bugfree and leaves
> never a spot uncleaned and never touched something that was not writen to

Isn't that the point of uninitialized access checking? I can't speak
to the scale of the problem because I don't know what the issues are.
In principle, you don't have to clear each uninitialized path of the
buffer that may occur due to an error. Instead, you should ensure that
the buffer is not accessed when the error occurs. If decoders rely on
external users to provide zeroed buffers to work correctly, then this
should be documented as an API requirement.

Outputting garbage on errors is acceptable, but if decoders process
uninitialized data internally when errors occur, they are, at best,
non-deterministic...

> Security wise this is not possible for production code, its too
> fragile (at least with the number of decoders and active maintainers we have)
> (you want less code to have to be bugfree for security not more code having
>  to be bug free)
>
> Now this is the fuzzer and not production code, ok. And of course is
> great to have error concealment in every decoder
> But then this leaves the question, who will do this work?
> If noone does it then we will accumulate many msan bugs in ossfuzz that we wont
> be able to do much with except ignore them.
> This would make the fuzzer less efficient and it would confuse people looking
> at the issues

MSAN is not forgiving, and I can imagine that stabilizing it could
take time. However, suppressing the reports will not make it more
efficient. I might not fully understand what you meant, though.

That being said, I think the patch makes sense as a short-term
solution to suppress the bulk of reports and focus on the remaining
ones. However, it would be good to make it clear that, at some point,
it should be reverted. As it stands now, no one will remember why it
was zeroed out, and it could remain that way indefinitely. Perhaps it
should be configurable per decoder.

> Or the short punchy reply maybe is
> Produce a volunteer who will fix these bugs before declaring them bugs.
> And when doing so consider that we have bugfixes on the mailing list for which we
> seem to not even have the man power to review and apply them
>
> so yeah my oppinion is the default should be the simple & easy to maintain way.
> If someone declares their decoder to have flawless error concealment (and for some
> simple decoders that could be quite simple) these can always be excluded and use
> uninitialized buffers in the fuzzer

What is the problem with keeping those reports and letting "someone"
work on their decoder based on reports?

- Kacper
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3902 bytes --]

Hi

On Fri, Aug 09, 2024 at 03:56:42AM +0200, Kacper Michajlow wrote:
> On Fri, 9 Aug 2024 at 00:06, Michael Niedermayer <michael@niedermayer.cc> wrote:
> >
> > On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
[...]
> > If decoders are fed with uninitialized buffers thats a
> > security issue because there are thousands if not ten thousands of
> > pathes if you consider the number of decoders and the number
> > of ways they can hit errors
> 
> Clearing those buffers in fuzzers does not alleviate this security
> issue, as they may still be uninitialized in production code.

The decoders in production clear the buffers. The fuzzer does not
so the issues it shows dont exist in production

look yourself in get_buffer.c

                pool->pools[i] = av_buffer_pool_init(size[i] + 16 + STRIDE_ALIGN - 1,
                                                     CONFIG_MEMORY_POISONING ?
                                                        NULL :
                                                        av_buffer_allocz);
its av_buffer_allocz


[...]
> > Security wise this is not possible for production code, its too
> > fragile (at least with the number of decoders and active maintainers we have)
> > (you want less code to have to be bugfree for security not more code having
> >  to be bug free)
> >
> > Now this is the fuzzer and not production code, ok. And of course is
> > great to have error concealment in every decoder
> > But then this leaves the question, who will do this work?
> > If noone does it then we will accumulate many msan bugs in ossfuzz that we wont
> > be able to do much with except ignore them.
> > This would make the fuzzer less efficient and it would confuse people looking
> > at the issues
> 
> MSAN is not forgiving, and I can imagine that stabilizing it could
> take time.

> However, suppressing the reports will not make it more
> efficient.

It will make it more efficient because then the fuzzer shows only issues
also affecting production and ones someone intends to work on
Otherwise it shows many issues that will distract and confuse


> I might not fully understand what you meant, though.

Yes, i think we misunderstand each other a bit


[...]

> Perhaps it
> should be configurable per decoder.

That is what i suggested, or at least i meant to.
For decoders where someone intends to fix every case where original buffer
data with nothing written into it come through it could make sense to enable
uninitialized input buffers.
Still i have not seen anyone actually want to do that. I certainly dont have the
time for any of the decoders that i maintain. But if someone else wants
i surely dont mind if (s)he turns this on and works on the additional cases for
any decoders that i maintain ...


> 
> > Or the short punchy reply maybe is
> > Produce a volunteer who will fix these bugs before declaring them bugs.
> > And when doing so consider that we have bugfixes on the mailing list for which we
> > seem to not even have the man power to review and apply them
> >
> > so yeah my oppinion is the default should be the simple & easy to maintain way.
> > If someone declares their decoder to have flawless error concealment (and for some
> > simple decoders that could be quite simple) these can always be excluded and use
> > uninitialized buffers in the fuzzer
> 
> What is the problem with keeping those reports and letting "someone"
> work on their decoder based on reports?

ossfuzz is the problem,
these issues are not seperate/segregated nor do i see a way ossfuzz could
seperate them but again ATM we have noone intending to work on this so
this patch solves it.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[James Almer]

On 8/9/2024 5:09 PM, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Aug 09, 2024 at 03:56:42AM +0200, Kacper Michajlow wrote:
>> On Fri, 9 Aug 2024 at 00:06, Michael Niedermayer <michael@niedermayer.cc> wrote:
>>>
>>> On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
> [...]
>>> If decoders are fed with uninitialized buffers thats a
>>> security issue because there are thousands if not ten thousands of
>>> pathes if you consider the number of decoders and the number
>>> of ways they can hit errors
>>
>> Clearing those buffers in fuzzers does not alleviate this security
>> issue, as they may still be uninitialized in production code.
> 
> The decoders in production clear the buffers. The fuzzer does not
> so the issues it shows dont exist in production
> 
> look yourself in get_buffer.c
> 
>                  pool->pools[i] = av_buffer_pool_init(size[i] + 16 + STRIDE_ALIGN - 1,
>                                                       CONFIG_MEMORY_POISONING ?
>                                                          NULL :
>                                                          av_buffer_allocz);
> its av_buffer_allocz

I disagree. That's from avcodec_default_get_buffer2(). What about DR1 
decoders where the caller is using their own avctx.get_buffer2() 
callback? Nothing in the documentation says that the buffers must be zeroed.

I wrote the function you just changed with the intention of finding 
issues a library user could trigger, which included allocating buffers 
exactly as big as needed (with no extra padding) and not zeroing it, 
using lavu helpers like the get_buffer2() documentation states.

This change here makes half of that moot, and is hiding potential bugs 
in the form of use of uninitialized memory in our decoders.

> 
> 
> [...]
>>> Security wise this is not possible for production code, its too
>>> fragile (at least with the number of decoders and active maintainers we have)
>>> (you want less code to have to be bugfree for security not more code having
>>>   to be bug free)
>>>
>>> Now this is the fuzzer and not production code, ok. And of course is
>>> great to have error concealment in every decoder
>>> But then this leaves the question, who will do this work?
>>> If noone does it then we will accumulate many msan bugs in ossfuzz that we wont
>>> be able to do much with except ignore them.
>>> This would make the fuzzer less efficient and it would confuse people looking
>>> at the issues
>>
>> MSAN is not forgiving, and I can imagine that stabilizing it could
>> take time.
> 
>> However, suppressing the reports will not make it more
>> efficient.
> 
> It will make it more efficient because then the fuzzer shows only issues
> also affecting production and ones someone intends to work on
> Otherwise it shows many issues that will distract and confuse
> 
> 
>> I might not fully understand what you meant, though.
> 
> Yes, i think we misunderstand each other a bit
> 
> 
> [...]
> 
>> Perhaps it
>> should be configurable per decoder.
> 
> That is what i suggested, or at least i meant to.
> For decoders where someone intends to fix every case where original buffer
> data with nothing written into it come through it could make sense to enable
> uninitialized input buffers.
> Still i have not seen anyone actually want to do that. I certainly dont have the
> time for any of the decoders that i maintain. But if someone else wants
> i surely dont mind if (s)he turns this on and works on the additional cases for
> any decoders that i maintain ...
> 
> 
>>
>>> Or the short punchy reply maybe is
>>> Produce a volunteer who will fix these bugs before declaring them bugs.
>>> And when doing so consider that we have bugfixes on the mailing list for which we
>>> seem to not even have the man power to review and apply them
>>>
>>> so yeah my oppinion is the default should be the simple & easy to maintain way.
>>> If someone declares their decoder to have flawless error concealment (and for some
>>> simple decoders that could be quite simple) these can always be excluded and use
>>> uninitialized buffers in the fuzzer
>>
>> What is the problem with keeping those reports and letting "someone"
>> work on their decoder based on reports?
> 
> ossfuzz is the problem,
> these issues are not seperate/segregated nor do i see a way ossfuzz could
> seperate them but again ATM we have noone intending to work on this so
> this patch solves it.
> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4144 bytes --]

On Sat, Aug 10, 2024 at 12:34:16PM -0300, James Almer wrote:
> On 8/9/2024 5:09 PM, Michael Niedermayer wrote:
> > Hi
> > 
> > On Fri, Aug 09, 2024 at 03:56:42AM +0200, Kacper Michajlow wrote:
> > > On Fri, 9 Aug 2024 at 00:06, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > > > 
> > > > On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
> > [...]
> > > > If decoders are fed with uninitialized buffers thats a
> > > > security issue because there are thousands if not ten thousands of
> > > > pathes if you consider the number of decoders and the number
> > > > of ways they can hit errors
> > > 
> > > Clearing those buffers in fuzzers does not alleviate this security
> > > issue, as they may still be uninitialized in production code.
> > 
> > The decoders in production clear the buffers. The fuzzer does not
> > so the issues it shows dont exist in production
> > 
> > look yourself in get_buffer.c
> > 
> >                  pool->pools[i] = av_buffer_pool_init(size[i] + 16 + STRIDE_ALIGN - 1,
> >                                                       CONFIG_MEMORY_POISONING ?
> >                                                          NULL :
> >                                                          av_buffer_allocz);
> > its av_buffer_allocz
> 
> I disagree. That's from avcodec_default_get_buffer2(). What about DR1
> decoders where the caller is using their own avctx.get_buffer2() callback?
> Nothing in the documentation says that the buffers must be zeroed.
> 
> I wrote the function you just changed with the intention of finding issues a
> library user could trigger, which included allocating buffers exactly as big
> as needed (with no extra padding) and not zeroing it, using lavu helpers
> like the get_buffer2() documentation states.
> 
> This change here makes half of that moot, and is hiding potential bugs in
> the form of use of uninitialized memory in our decoders.

we have several sanitizers, msan is just one of them
outside msan, using uninitialized buffers is only having one effect and that
is it makes things less reproducable

using uninitialized buffers is a security issue. Its a secuirty issue
because many of our decoders pass uninitialized data through on errors.
An attacker uploads a file with error and gets a encoded file back, that
encoded file now contains what was in the memory of these uninitialized buffers
An attacker is not supposed to be able to read your memory like that

we have 481 DR1 decoders. For the use for uninitialized buffers to be safe
you need to have every error path on every of these decoders to clean every bit of
the buffer that was not initialized.
This is not how you design secure software
Design that needs "every" multiplied by "every" to do a specific thing is bad security

noone volunteered to make all the decoders handle uninitialized buffers
Simply making these issues appear in ossfuzz doesnt fix them

IMHO
If someone wants to work on uninitialized buffer support and fixes, perfectly
fine with me. What i do not agree to is the attempt to force the already very
busy people to work on and fix these issues when a simply "memset()" avoids
the whole issue

Again, on one hand one memset() on the other 481 DR1 decoders that clear the right
bits of the buffer on EVERY error path.

Thats like strlcpy() vs strcpy() with no bugs on any use. We know which of this
is a bad idea. Why is it here something we argue about ?
because DR1 doesnt document that the buffer contents can leak through (which
really is what it should say not "you must clear it")
Its good enough if the user app ensures the buffer contains no sensitive data

and no matter how hard we try to fix all decoders so they never leak something
thorugh. we should still say the custom buffers should not contain sensitive
data, so iam not sure but i dont think we disagree here or do we ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/6] tools/target_dec_fuzzer: Use av_buffer_allocz() to avoid missing slices to have unpredictable content

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 46583 bytes --]

On Mon, Aug 12, 2024 at 09:02:00PM +0200, Michael Niedermayer wrote:
> On Sat, Aug 10, 2024 at 12:34:16PM -0300, James Almer wrote:
> > On 8/9/2024 5:09 PM, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Fri, Aug 09, 2024 at 03:56:42AM +0200, Kacper Michajlow wrote:
> > > > On Fri, 9 Aug 2024 at 00:06, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > > > > 
> > > > > On Thu, Aug 08, 2024 at 02:13:12PM -0300, James Almer wrote:
> > > [...]
> > > > > If decoders are fed with uninitialized buffers thats a
> > > > > security issue because there are thousands if not ten thousands of
> > > > > pathes if you consider the number of decoders and the number
> > > > > of ways they can hit errors
> > > > 
> > > > Clearing those buffers in fuzzers does not alleviate this security
> > > > issue, as they may still be uninitialized in production code.
> > > 
> > > The decoders in production clear the buffers. The fuzzer does not
> > > so the issues it shows dont exist in production
> > > 
> > > look yourself in get_buffer.c
> > > 
> > >                  pool->pools[i] = av_buffer_pool_init(size[i] + 16 + STRIDE_ALIGN - 1,
> > >                                                       CONFIG_MEMORY_POISONING ?
> > >                                                          NULL :
> > >                                                          av_buffer_allocz);
> > > its av_buffer_allocz
> > 
> > I disagree. That's from avcodec_default_get_buffer2(). What about DR1
> > decoders where the caller is using their own avctx.get_buffer2() callback?
> > Nothing in the documentation says that the buffers must be zeroed.
> > 
> > I wrote the function you just changed with the intention of finding issues a
> > library user could trigger, which included allocating buffers exactly as big
> > as needed (with no extra padding) and not zeroing it, using lavu helpers
> > like the get_buffer2() documentation states.
> > 
> > This change here makes half of that moot, and is hiding potential bugs in
> > the form of use of uninitialized memory in our decoders.
> 
> we have several sanitizers, msan is just one of them
> outside msan, using uninitialized buffers is only having one effect and that
> is it makes things less reproducable
> 
> using uninitialized buffers is a security issue. Its a secuirty issue
> because many of our decoders pass uninitialized data through on errors.
> An attacker uploads a file with error and gets a encoded file back, that
> encoded file now contains what was in the memory of these uninitialized buffers
> An attacker is not supposed to be able to read your memory like that
> 
> we have 481 DR1 decoders. For the use for uninitialized buffers to be safe
> you need to have every error path on every of these decoders to clean every bit of
> the buffer that was not initialized.
> This is not how you design secure software
> Design that needs "every" multiplied by "every" to do a specific thing is bad security
> 
> noone volunteered to make all the decoders handle uninitialized buffers
> Simply making these issues appear in ossfuzz doesnt fix them
> 
> IMHO
> If someone wants to work on uninitialized buffer support and fixes, perfectly
> fine with me. What i do not agree to is the attempt to force the already very
> busy people to work on and fix these issues when a simply "memset()" avoids
> the whole issue
> 
> Again, on one hand one memset() on the other 481 DR1 decoders that clear the right
> bits of the buffer on EVERY error path.
> 
> Thats like strlcpy() vs strcpy() with no bugs on any use. We know which of this
> is a bad idea. Why is it here something we argue about ?
> because DR1 doesnt document that the buffer contents can leak through (which
> really is what it should say not "you must clear it")
> Its good enough if the user app ensures the buffer contains no sensitive data
> 
> and no matter how hard we try to fix all decoders so they never leak something
> thorugh. we should still say the custom buffers should not contain sensitive
> data, so iam not sure but i dont think we disagree here or do we ?
> 
> thx

Also if someone wants to look at decoders passing uninitialized data thorugh
here are a few

70836
    #0 0x567ec5e29ae1 in ff_add_png_paeth_prediction /src/ffmpeg/libavcodec/pngdec.c:236:22
    #1 0x567ec5e2a96f in ff_png_filter_row /src/ffmpeg/libavcodec/pngdec.c:330:17
    #2 0x567ec5de85ca in handle_row /src/ffmpeg/libavcodec/lscrdec.c:71:5
    #3 0x567ec5de85ca in decode_idat /src/ffmpeg/libavcodec/lscrdec.c:97:17
    #4 0x567ec5de85ca in decode_frame_lscr /src/ffmpeg/libavcodec/lscrdec.c:193:19
    #5 0x567ec5dca27b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #6 0x567ec5dca27b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #7 0x567ec5dca27b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #8 0x567ec5dc97e3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #9 0x567ec5db72bc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #10 0x567ec5cb0a20 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #11 0x567ec5c9b1b4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #12 0x567ec5ca0c4a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #13 0x567ec5ccd042 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #14 0x7dd57860d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #15 0x567ec5c91c8d in _start
  Uninitialized value was created by a heap allocation
    #0 0x567ec5d53603 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x567ec6564b48 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x567ec6517df2 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x567ec5db9c46 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x567ec5db9c46 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x567ec5dd54b0 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x567ec5dd6707 in reget_buffer_internal /src/ffmpeg/libavcodec/decode.c:1661:16
    #7 0x567ec5dd6707 in ff_reget_buffer /src/ffmpeg/libavcodec/decode.c:1686:15
    #8 0x567ec5de6cd9 in decode_frame_lscr /src/ffmpeg/libavcodec/lscrdec.c:130:11
    #9 0x567ec5dca27b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #10 0x567ec5dca27b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #11 0x567ec5dca27b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #12 0x567ec5dc97e3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #13 0x567ec5db72bc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #14 0x567ec5cb0a20 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #15 0x567ec5c9b1b4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #16 0x567ec5ca0c4a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #17 0x567ec5ccd042 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #18 0x7dd57860d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16

70838 (i already fixed this one)
    #0 0x593ba893f86c in add_left_pred_c /src/ffmpeg/libavcodec/lossless_videodsp.c:80:5
    #1 0x593ba85617ba in decode_frame /src/ffmpeg/libavcodec/mvha.c:262:9
    #2 0x593ba850f1bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #3 0x593ba850f1bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #4 0x593ba850f1bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #5 0x593ba850e723 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #6 0x593ba84fc1fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #7 0x593ba83f5960 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #8 0x593ba83e00f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #9 0x593ba83e5b8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #10 0x593ba8411f82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #11 0x7cbc84ec4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #12 0x593ba83d6bcd in _start
  Uninitialized value was stored to memory at
    #0 0x593ba893f6c6 in add_left_pred_c /src/ffmpeg/libavcodec/lossless_videodsp.c:69:16
    #1 0x593ba85617ba in decode_frame /src/ffmpeg/libavcodec/mvha.c:262:9
    #2 0x593ba850f1bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #3 0x593ba850f1bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #4 0x593ba850f1bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #5 0x593ba850e723 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #6 0x593ba84fc1fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #7 0x593ba83f5960 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #8 0x593ba83e00f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #9 0x593ba83e5b8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #10 0x593ba8411f82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #11 0x7cbc84ec4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was stored to memory at
    #0 0x593ba893f70b in add_left_pred_c /src/ffmpeg/libavcodec/lossless_videodsp.c:72:16
    #1 0x593ba85617ba in decode_frame /src/ffmpeg/libavcodec/mvha.c:262:9
    #2 0x593ba850f1bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #3 0x593ba850f1bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #4 0x593ba850f1bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #5 0x593ba850e723 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #6 0x593ba84fc1fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #7 0x593ba83f5960 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #8 0x593ba83e00f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #9 0x593ba83e5b8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #10 0x593ba8411f82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #11 0x7cbc84ec4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was stored to memory at
    #0 0x593ba893f6c6 in add_left_pred_c /src/ffmpeg/libavcodec/lossless_videodsp.c:69:16
    #1 0x593ba85617ba in decode_frame /src/ffmpeg/libavcodec/mvha.c:262:9
    #2 0x593ba850f1bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #3 0x593ba850f1bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #4 0x593ba850f1bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #5 0x593ba850e723 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #6 0x593ba84fc1fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #7 0x593ba83f5960 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #8 0x593ba83e00f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #9 0x593ba83e5b8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #10 0x593ba8411f82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #11 0x7cbc84ec4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was created by a heap allocation
    #0 0x593ba8498543 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x593ba8c904c8 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x593ba8c44ac2 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x593ba84feb86 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x593ba84feb86 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x593ba851a3f0 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x593ba8560d57 in decode_frame /src/ffmpeg/libavcodec/mvha.c:170:20
    #7 0x593ba850f1bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #8 0x593ba850f1bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #9 0x593ba850f1bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #10 0x593ba850e723 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #11 0x593ba84fc1fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #12 0x593ba83f5960 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #13 0x593ba83e00f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #14 0x593ba83e5b8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #15 0x593ba8411f82 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #16 0x7cbc84ec4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16

70848
    #0 0x59d52678fcd5 in av_clip_c /src/ffmpeg/libavutil/common.h:183:14
    #1 0x59d52678fcd5 in filter181 /src/ffmpeg/libavcodec/error_resilience.c:125:19
    #2 0x59d52678fcd5 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1281:5
    #3 0x59d52670f498 in finish_frame /src/ffmpeg/libavcodec/rv34.c:1582:5
    #4 0x59d526702d83 in ff_rv34_decode_frame /src/ffmpeg/libavcodec/rv34.c:1802:19
    #5 0x59d526111a6b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #6 0x59d526111a6b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #7 0x59d526111a6b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #8 0x59d526110fd3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #9 0x59d5260feaac in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #10 0x59d525ff8210 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #11 0x59d525fe29a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #12 0x59d525fe843a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #13 0x59d526014832 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #14 0x7b1cb6cc5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #15 0x59d525fd947d in _start
  Uninitialized value was stored to memory at
    #0 0x59d52678dad2 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1255:59
    #1 0x59d52670f498 in finish_frame /src/ffmpeg/libavcodec/rv34.c:1582:5
    #2 0x59d526702d83 in ff_rv34_decode_frame /src/ffmpeg/libavcodec/rv34.c:1802:19
    #3 0x59d526111a6b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #4 0x59d526111a6b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #5 0x59d526111a6b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #6 0x59d526110fd3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #7 0x59d5260feaac in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #8 0x59d525ff8210 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #9 0x59d525fe29a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #10 0x59d525fe843a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #11 0x59d526014832 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #12 0x7b1cb6cc5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was stored to memory at
    #0 0x59d5265f7d5d in put_pixels8_8_c /src/ffmpeg/libavcodec/pel_template.c:78:1
    #1 0x59d5265f7d5d in put_pixels16_8_c /src/ffmpeg/libavcodec/pel_template.c:78:1
    #2 0x59d5266b6455 in mpeg_motion_internal /src/ffmpeg/libavcodec/mpegvideo_motion.c:205:5
    #3 0x59d5266b6455 in mpeg_motion /src/ffmpeg/libavcodec/mpegvideo_motion.c:232:9
    #4 0x59d5266b3606 in mpv_motion_internal /src/ffmpeg/libavcodec/mpegvideo_motion.c:0
    #5 0x59d5266b3606 in ff_mpv_motion /src/ffmpeg/libavcodec/mpegvideo_motion.c:0
    #6 0x59d526697988 in mpv_reconstruct_mb_internal /src/ffmpeg/libavcodec/mpv_reconstruct_mb_template.c:147:21
    #7 0x59d526697988 in ff_mpv_reconstruct_mb /src/ffmpeg/libavcodec/mpegvideo_dec.c:930:13
    #8 0x59d5267925c1 in guess_mv /src/ffmpeg/libavcodec/error_resilience.c:456:17
    #9 0x59d52678d549 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1224:9
    #10 0x59d52670f498 in finish_frame /src/ffmpeg/libavcodec/rv34.c:1582:5
    #11 0x59d526702d83 in ff_rv34_decode_frame /src/ffmpeg/libavcodec/rv34.c:1802:19
    #12 0x59d526111a6b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #13 0x59d526111a6b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #14 0x59d526111a6b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #15 0x59d526110fd3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #16 0x59d5260feaac in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #17 0x59d525ff8210 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #18 0x59d525fe29a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #19 0x59d525fe843a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #20 0x59d526014832 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #21 0x7b1cb6cc5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was created by a heap allocation
    #0 0x59d52609adf3 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x59d526982dc8 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x59d5269373c2 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x59d526101436 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x59d526101436 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x59d52611cca0 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x59d526175c29 in thread_get_buffer_internal /src/ffmpeg/libavcodec/pthread_frame.c:969:16
    #7 0x59d526175c29 in ff_thread_get_buffer /src/ffmpeg/libavcodec/pthread_frame.c:988:15
    #8 0x59d526690078 in alloc_picture /src/ffmpeg/libavcodec/mpegvideo_dec.c:234:15
    #9 0x59d525fcc4a2 in alloc_dummy_frame /src/ffmpeg/libavcodec/mpegvideo_dec.c:271:15
    #10 0x59d52668ed1c in ff_mpv_alloc_dummy_frames /src/ffmpeg/libavcodec/mpegvideo_dec.c:318:15
    #11 0x59d52668f9ae in ff_mpv_frame_start /src/ffmpeg/libavcodec/mpegvideo_dec.c:384:11
    #12 0x59d526702afc in ff_rv34_decode_frame /src/ffmpeg/libavcodec/rv34.c:1706:13
    #13 0x59d526111a6b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #14 0x59d526111a6b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #15 0x59d526111a6b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #16 0x59d526110fd3 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #17 0x59d5260feaac in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #18 0x59d525ff8210 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #19 0x59d525fe29a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #20 0x59d525fe843a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #21 0x59d526014832 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #22 0x7b1cb6cc5082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #0 0x57ffd5699628 in loop_filter /src/ffmpeg/libavcodec/vp9dsp_template.c:1796:38
    #1 0x57ffd5699628 in loop_filter_v_8_8_c /src/ffmpeg/libavcodec/vp9dsp_template.c:1906:1
    #2 0x57ffd5721d2c in filter_plane_rows /src/ffmpeg/libavcodec/vp9lpf.c:0:25
    #3 0x57ffd5721d2c in ff_vp9_loopfilter_sb /src/ffmpeg/libavcodec/vp9lpf.c:201:9
    #4 0x57ffd55d64a8 in decode_tiles /src/ffmpeg/libavcodec/vp9.c:1372:21
    #5 0x57ffd55d64a8 in vp9_decode_frame /src/ffmpeg/libavcodec/vp9.c:1716:19
    #6 0x57ffd552c5bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #7 0x57ffd552c5bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #8 0x57ffd552c5bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #9 0x57ffd552bb23 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #10 0x57ffd55195fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #11 0x57ffd5412d60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #12 0x57ffd53fd4f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #13 0x57ffd5402f8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #14 0x57ffd542f382 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #15 0x7c7d13998082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #16 0x57ffd53f3fcd in _start
  Uninitialized value was created by a heap allocation
    #0 0x57ffd54b5943 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x57ffd5f209e8 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x57ffd5ed4fe2 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x57ffd551bf86 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x57ffd551bf86 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x57ffd55377f0 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x57ffd5590779 in thread_get_buffer_internal /src/ffmpeg/libavcodec/pthread_frame.c:969:16
    #7 0x57ffd5590779 in ff_thread_get_buffer /src/ffmpeg/libavcodec/pthread_frame.c:988:15
    #8 0x57ffd5538d8a in ff_progress_frame_get_buffer /src/ffmpeg/libavcodec/decode.c:1725:11
    #9 0x57ffd55d19fb in vp9_frame_alloc /src/ffmpeg/libavcodec/vp9.c:110:11
    #10 0x57ffd55d19fb in vp9_decode_frame /src/ffmpeg/libavcodec/vp9.c:1588:16
    #11 0x57ffd552c5bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #12 0x57ffd552c5bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #13 0x57ffd552c5bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #14 0x57ffd552bb23 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #15 0x57ffd55195fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #16 0x57ffd5412d60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #17 0x57ffd53fd4f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #18 0x57ffd5402f8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #19 0x57ffd542f382 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #20 0x7c7d13998082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16

70858
    #0 0x57ffd5699628 in loop_filter /src/ffmpeg/libavcodec/vp9dsp_template.c:1796:38
    #1 0x57ffd5699628 in loop_filter_v_8_8_c /src/ffmpeg/libavcodec/vp9dsp_template.c:1906:1
    #2 0x57ffd5721d2c in filter_plane_rows /src/ffmpeg/libavcodec/vp9lpf.c:0:25
    #3 0x57ffd5721d2c in ff_vp9_loopfilter_sb /src/ffmpeg/libavcodec/vp9lpf.c:201:9
    #4 0x57ffd55d64a8 in decode_tiles /src/ffmpeg/libavcodec/vp9.c:1372:21
    #5 0x57ffd55d64a8 in vp9_decode_frame /src/ffmpeg/libavcodec/vp9.c:1716:19
    #6 0x57ffd552c5bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #7 0x57ffd552c5bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #8 0x57ffd552c5bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #9 0x57ffd552bb23 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #10 0x57ffd55195fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #11 0x57ffd5412d60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #12 0x57ffd53fd4f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #13 0x57ffd5402f8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #14 0x57ffd542f382 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #15 0x7c7d13998082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #16 0x57ffd53f3fcd in _start
  Uninitialized value was created by a heap allocation
    #0 0x57ffd54b5943 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x57ffd5f209e8 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x57ffd5ed4fe2 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x57ffd551bf86 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x57ffd551bf86 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x57ffd55377f0 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x57ffd5590779 in thread_get_buffer_internal /src/ffmpeg/libavcodec/pthread_frame.c:969:16
    #7 0x57ffd5590779 in ff_thread_get_buffer /src/ffmpeg/libavcodec/pthread_frame.c:988:15
    #8 0x57ffd5538d8a in ff_progress_frame_get_buffer /src/ffmpeg/libavcodec/decode.c:1725:11
    #9 0x57ffd55d19fb in vp9_frame_alloc /src/ffmpeg/libavcodec/vp9.c:110:11
    #10 0x57ffd55d19fb in vp9_decode_frame /src/ffmpeg/libavcodec/vp9.c:1588:16
    #11 0x57ffd552c5bb in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #12 0x57ffd552c5bb in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #13 0x57ffd552c5bb in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #14 0x57ffd552bb23 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #15 0x57ffd55195fc in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #16 0x57ffd5412d60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #17 0x57ffd53fd4f4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #18 0x57ffd5402f8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #19 0x57ffd542f382 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #20 0x7c7d13998082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16

70870
  #0 0x5c9ac4ef5b92 in av_clip_c /src/ffmpeg/libavutil/common.h:183:14
    #1 0x5c9ac4ef5b92 in filter181 /src/ffmpeg/libavcodec/error_resilience.c:109:19
    #2 0x5c9ac4ef5b92 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1281:5
    #3 0x5c9ac4be8ebe in slice_end /src/ffmpeg/libavcodec/mpeg12dec.c:1740:9
    #4 0x5c9ac4be8ebe in decode_chunks /src/ffmpeg/libavcodec/mpeg12dec.c:2198:23
    #5 0x5c9ac4bd65ce in mpeg_decode_frame /src/ffmpeg/libavcodec/mpeg12dec.c:2546:11
    #6 0x5c9ac4b83e2b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #7 0x5c9ac4b83e2b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #8 0x5c9ac4b83e2b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #9 0x5c9ac4b83393 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #10 0x5c9ac4b70e6c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #11 0x5c9ac4a6a5d0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #12 0x5c9ac4a54d64 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #13 0x5c9ac4a5a7fa in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #14 0x5c9ac4a86bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #15 0x7edc6d9b0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #16 0x5c9ac4a4b83d in _start
  Uninitialized value was stored to memory at
    #0 0x5c9ac4ef39a2 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1255:59
    #1 0x5c9ac4be8ebe in slice_end /src/ffmpeg/libavcodec/mpeg12dec.c:1740:9
    #2 0x5c9ac4be8ebe in decode_chunks /src/ffmpeg/libavcodec/mpeg12dec.c:2198:23
    #3 0x5c9ac4bd65ce in mpeg_decode_frame /src/ffmpeg/libavcodec/mpeg12dec.c:2546:11
    #4 0x5c9ac4b83e2b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #5 0x5c9ac4b83e2b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #6 0x5c9ac4b83e2b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #7 0x5c9ac4b83393 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #8 0x5c9ac4b70e6c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #9 0x5c9ac4a6a5d0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #10 0x5c9ac4a54d64 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #11 0x5c9ac4a5a7fa in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #12 0x5c9ac4a86bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #13 0x7edc6d9b0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was stored to memory at
    #0 0x5c9ac500cb9c in put_pixels8_8_c /src/ffmpeg/libavcodec/pel_template.c:78:1
    #1 0x5c9ac500cb9c in put_pixels16_8_c /src/ffmpeg/libavcodec/pel_template.c:78:1
    #2 0x5c9ac4c2f170 in mpeg_motion_internal /src/ffmpeg/libavcodec/mpegvideo_motion.c:205:5
    #3 0x5c9ac4c2f170 in mpeg_motion /src/ffmpeg/libavcodec/mpegvideo_motion.c:227:9
    #4 0x5c9ac4c2bc46 in mpv_motion_internal /src/ffmpeg/libavcodec/mpegvideo_motion.c:0
    #5 0x5c9ac4c2bc46 in ff_mpv_motion /src/ffmpeg/libavcodec/mpegvideo_motion.c:0
    #6 0x5c9ac4c0cc7e in mpv_reconstruct_mb_internal /src/ffmpeg/libavcodec/mpv_reconstruct_mb_template.c:147:21
    #7 0x5c9ac4c0cc7e in ff_mpv_reconstruct_mb /src/ffmpeg/libavcodec/mpegvideo_dec.c:928:13
    #8 0x5c9ac4ef8491 in guess_mv /src/ffmpeg/libavcodec/error_resilience.c:456:17
    #9 0x5c9ac4ef3419 in ff_er_frame_end /src/ffmpeg/libavcodec/error_resilience.c:1224:9
    #10 0x5c9ac4be8ebe in slice_end /src/ffmpeg/libavcodec/mpeg12dec.c:1740:9
    #11 0x5c9ac4be8ebe in decode_chunks /src/ffmpeg/libavcodec/mpeg12dec.c:2198:23
    #12 0x5c9ac4bd65ce in mpeg_decode_frame /src/ffmpeg/libavcodec/mpeg12dec.c:2546:11
    #13 0x5c9ac4b83e2b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #14 0x5c9ac4b83e2b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #15 0x5c9ac4b83e2b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #16 0x5c9ac4b83393 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #17 0x5c9ac4b70e6c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #18 0x5c9ac4a6a5d0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #19 0x5c9ac4a54d64 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #20 0x5c9ac4a5a7fa in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #21 0x5c9ac4a86bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #22 0x7edc6d9b0082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  Uninitialized value was created by a heap allocation
    #0 0x5c9ac4b0d1b3 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x5c9ac5326e38 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x5c9ac52db432 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x5c9ac4b737f6 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x5c9ac4b737f6 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x5c9ac4b8f060 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x5c9ac4c44829 in thread_get_buffer_internal /src/ffmpeg/libavcodec/pthread_frame.c:969:16
    #7 0x5c9ac4c44829 in ff_thread_get_buffer /src/ffmpeg/libavcodec/pthread_frame.c:988:15
    #8 0x5c9ac4c086b8 in alloc_picture /src/ffmpeg/libavcodec/mpegvideo_dec.c:234:15
    #9 0x5c9ac4a3604b in alloc_dummy_frame /src/ffmpeg/libavcodec/mpegvideo_dec.c:271:15
    #10 0x5c9ac4c0735c in ff_mpv_alloc_dummy_frames /src/ffmpeg/libavcodec/mpegvideo_dec.c:318:15
    #11 0x5c9ac4c07fee in ff_mpv_frame_start /src/ffmpeg/libavcodec/mpegvideo_dec.c:384:11
    #12 0x5c9ac4beb6b8 in mpeg_field_start /src/ffmpeg/libavcodec/mpeg12dec.c:1268:20
    #13 0x5c9ac4be18f2 in decode_chunks /src/ffmpeg/libavcodec/mpeg12dec.c:2446:32
    #14 0x5c9ac4bd65ce in mpeg_decode_frame /src/ffmpeg/libavcodec/mpeg12dec.c:2546:11
    #15 0x5c9ac4b83e2b in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #16 0x5c9ac4b83e2b in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #17 0x5c9ac4b83e2b in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #18 0x5c9ac4b83393 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #19 0x5c9ac4b70e6c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #20 0x5c9ac4a6a5d0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #21 0x5c9ac4a54d64 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #22 0x5c9ac4a5a7fa in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #23 0x5c9ac4a86bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10

70928
=6524==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x5c2c3d950a9b in run_postproc /src/ffmpeg/libavcodec/dds.c:483:21
    #1 0x5c2c3d94acc0 in dds_decode /src/ffmpeg/libavcodec/dds.c:711:9
    #2 0x5c2c3d9529db in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #3 0x5c2c3d9529db in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #4 0x5c2c3d9529db in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #5 0x5c2c3d951f43 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #6 0x5c2c3d93624c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #7 0x5c2c3d82f9b0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #8 0x5c2c3d81a144 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #9 0x5c2c3d81fbda in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #10 0x5c2c3d84bfd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #11 0x7ce16e94d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
    #12 0x5c2c3d810c1d in _start
  Uninitialized value was created by a heap allocation
    #0 0x5c2c3d8d2593 in ___interceptor_posix_memalign /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:162:3
    #1 0x5c2c3e0d2798 in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
    #2 0x5c2c3e086d92 in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
    #3 0x5c2c3d938bd6 in fuzz_video_get_buffer /src/ffmpeg/tools/target_dec_fuzzer.c:132:25
    #4 0x5c2c3d938bd6 in fuzz_get_buffer2 /src/ffmpeg/tools/target_dec_fuzzer.c:153:18
    #5 0x5c2c3d95dc10 in ff_get_buffer /src/ffmpeg/libavcodec/decode.c:1621:11
    #6 0x5c2c3d949f58 in dds_decode /src/ffmpeg/libavcodec/dds.c:618:11
    #7 0x5c2c3d9529db in decode_simple_internal /src/ffmpeg/libavcodec/decode.c:429:20
    #8 0x5c2c3d9529db in decode_simple_receive_frame /src/ffmpeg/libavcodec/decode.c:600:15
    #9 0x5c2c3d9529db in decode_receive_frame_internal /src/ffmpeg/libavcodec/decode.c:631:15
    #10 0x5c2c3d951f43 in avcodec_send_packet /src/ffmpeg/libavcodec/decode.c:721:15
    #11 0x5c2c3d93624c in LLVMFuzzerTestOneInput /src/ffmpeg/tools/target_dec_fuzzer.c:534:25
    #12 0x5c2c3d82f9b0 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:614:13
    #13 0x5c2c3d81a144 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:327:6
    #14 0x5c2c3d81fbda in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:862:9
    #15 0x5c2c3d84bfd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #16 0x7ce16e94d082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16


Ohh and maybe also all these that ossfuzz stuffed into a unrelated adpcm issue they look suspicously related to the
issues above.

Use-of-uninitialized-value Mon, Aug 12, 2024, 4:22 PM 	Project ffmpeg Platform linux Reliably reproduces Security
decode_format80
vqa_decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Mon, Aug 12, 2024, 7:42 AM 	Project ffmpeg Platform linux Reliably reproduces Security
imc_decode_frame
decode_receive_frame_internal
avcodec_send_packet
Issue 70618
Use-of-uninitialized-value Sun, Aug 11, 2024, 11:30 AM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
vp3_v_loop_filter_8_c
apply_loop_filter
vp3_decode_frame
Issue 70618
Use-of-uninitialized-value Sun, Aug 11, 2024, 4:31 AM 	Project ffmpeg Platform linux Reliably reproduces Security
decompress_p3
decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Sat, Aug 10, 2024, 2:00 AM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
decode_nal_units
hevc_decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Fri, Aug 9, 2024, 5:19 PM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
vp3_h_loop_filter_8_c
apply_loop_filter
vp3_decode_frame
Issue 70618
Use-of-uninitialized-value Fri, Aug 9, 2024, 12:48 PM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
ff_vp3dsp_h_loop_filter_12
vp3_decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Fri, Aug 9, 2024, 3:57 AM 	Project ffmpeg Platform linux Reliably reproduces Security
ff_dsd2pcm_translate
decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Thu, Aug 8, 2024, 7:35 PM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
rv30_loop_filter
ff_rv34_decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Thu, Aug 8, 2024, 2:46 PM 	Project ffmpeg Platform linux Reliably reproduces Security
decode_frame
decode_receive_frame_internal
ff_decode_receive_frame
Issue 70618
Use-of-uninitialized-value Thu, Aug 8, 2024, 4:42 AM 	Project ffmpeg Platform linux Reliably reproduces Security
rv30_loop_filter
rv34_decode_slice
ff_rv34_decode_frame
Issue 71025
Use-of-uninitialized-value Thu, Aug 8, 2024, 4:13 AM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
loop_filter_h_4_8_c
ff_vp9_loopfilter_sb
vp9_decode_frame
Issue 70618
Use-of-uninitialized-value Thu, Aug 8, 2024, 3:03 AM 	Project ffmpeg Platform linux Reliably reproduces Security
decompress_p
decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Wed, Aug 7, 2024, 11:55 PM 	Project ffmpeg Platform linux Reliably reproduces Security
ff_h274_apply_film_grain
decode_nal_units
hevc_decode_frame
Issue 71021
Use-of-uninitialized-value Wed, Aug 7, 2024, 4:03 AM 	Project ffmpeg Platform linux Reliably reproduces Security
add_median_pred_c
decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Tue, Aug 6, 2024, 9:37 PM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
ff_er_frame_end
ff_h263_decode_frame
decode_receive_frame_internal
Issue 70618
Use-of-uninitialized-value Sat, Aug 3, 2024, 6:52 PM 	Project ffmpeg Platform linux Reliably reproduces Security
tgq_decode_frame
decode_receive_frame_internal
avcodec_send_packet
Issue 70618
Use-of-uninitialized-value Sat, Aug 3, 2024, 4:18 PM 	Project ffmpeg Platform linux Reliably reproduces Security
guess_mv
ff_er_frame_end
vc1_decode_frame
Issue 70926
Use-of-uninitialized-value Fri, Aug 2, 2024, 11:31 AM 	Fixed Project ffmpeg Platform linux Reliably reproduces Security
mp_decode_frame
decode_receive_frame_internal
avcodec_send_packet
Issue 70618
Use-of-uninitialized-value Fri, Aug 2, 2024, 1:19 AM 	Project ffmpeg Platform linux Reliably reproduces Security
decode_frame
decode_receive_frame_internal
avcodec_send_packet
Issue 70618
Use-of-uninitialized-value Thu, Aug 1, 2024, 2:33 PM 	Project ffmpeg Platform linux Reliably reproduces Security
loop_filter_v_8_8_c
ff_vp9_loopfilter_sb
vp9_decode_frame
Issue 70858
Use-of-uninitialized-value Thu, Aug 1, 2024, 7:57 AM 	Project ffmpeg Platform linux Reliably reproduces Security
ff_er_frame_end
finish_frame
ff_rv34_decode_frame
Issue 70848
Use-of-uninitialized-value Thu, Aug 1, 2024, 2:27 AM 	Project ffmpeg Platform linux Reliably reproduces Security
add_left_pred_c
decode_frame
decode_receive_frame_internal
Issue 70838
Use-of-uninitialized-value Wed, Jul 31, 2024, 11:08 PM 	Project ffmpeg Platform linux Reliably reproduces Security
ff_add_png_paeth_prediction
ff_png_filter_row
decode_frame_lscr
Issue 70836

thx

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 6/6] avformat/wtvdec: Check length of read mpeg2_descriptor

[Michael Niedermayer]

Fixes: Use of uninitialized value
Fixes: 70900/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6286909377150976

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/wtvdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index 1a6c4c33481..730c7fca783 100644
--- a/libavformat/wtvdec.c
+++ b/libavformat/wtvdec.c
@@ -846,7 +846,8 @@ static int parse_chunks(AVFormatContext *s, int mode, int64_t seekts, int *len_p
                 }
 
                 buf_size = FFMIN(len - consumed, sizeof(buf));
-                avio_read(pb, buf, buf_size);
+                if (avio_read(pb, buf, buf_size) != buf_size)
+                    return AVERROR_INVALIDDATA;
                 consumed += buf_size;
                 ff_parse_mpeg2_descriptor(s, st, 0, &pbuf, buf + buf_size, NULL, 0, 0, NULL);
             }
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 6/6] avformat/wtvdec: Check length of read mpeg2_descriptor

[Peter Ross]

[-- Attachment #1.1: Type: text/plain, Size: 1224 bytes --]

On Wed, Aug 07, 2024 at 12:18:53AM +0200, Michael Niedermayer wrote:
> Fixes: Use of uninitialized value
> Fixes: 70900/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6286909377150976
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavformat/wtvdec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> index 1a6c4c33481..730c7fca783 100644
> --- a/libavformat/wtvdec.c
> +++ b/libavformat/wtvdec.c
> @@ -846,7 +846,8 @@ static int parse_chunks(AVFormatContext *s, int mode, int64_t seekts, int *len_p
>                  }
>  
>                  buf_size = FFMIN(len - consumed, sizeof(buf));
> -                avio_read(pb, buf, buf_size);
> +                if (avio_read(pb, buf, buf_size) != buf_size)
> +                    return AVERROR_INVALIDDATA;
>                  consumed += buf_size;
>                  ff_parse_mpeg2_descriptor(s, st, 0, &pbuf, buf + buf_size, NULL, 0, 0, NULL);
>              }

please apply

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 6/6] avformat/wtvdec: Check length of read mpeg2_descriptor

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1527 bytes --]

On Wed, Aug 07, 2024 at 10:02:09AM +1000, Peter Ross wrote:
> On Wed, Aug 07, 2024 at 12:18:53AM +0200, Michael Niedermayer wrote:
> > Fixes: Use of uninitialized value
> > Fixes: 70900/clusterfuzz-testcase-minimized-ffmpeg_dem_WTV_fuzzer-6286909377150976
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavformat/wtvdec.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
> > index 1a6c4c33481..730c7fca783 100644
> > --- a/libavformat/wtvdec.c
> > +++ b/libavformat/wtvdec.c
> > @@ -846,7 +846,8 @@ static int parse_chunks(AVFormatContext *s, int mode, int64_t seekts, int *len_p
> >                  }
> >  
> >                  buf_size = FFMIN(len - consumed, sizeof(buf));
> > -                avio_read(pb, buf, buf_size);
> > +                if (avio_read(pb, buf, buf_size) != buf_size)
> > +                    return AVERROR_INVALIDDATA;
> >                  consumed += buf_size;
> >                  ff_parse_mpeg2_descriptor(s, st, 0, &pbuf, buf + buf_size, NULL, 0, 0, NULL);
> >              }
> 
> please apply

will apply

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avformat/segafilm: Set keyframe

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]

On Wed, Aug 07, 2024 at 12:18:48AM +0200, Michael Niedermayer wrote:
> Fixes: use of uninitialized value
> Fixes: 70871/clusterfuzz-testcase-minimized-ffmpeg_dem_SEGAFILM_fuzzer-5883617752973312
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavformat/segafilm.c | 1 +
>  1 file changed, 1 insertion(+)

will apply patches 1-3

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".