| Message ID | 20210720202942.8574-4-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | 1e85a698c01133a7f8d35502d5901e3b65fa3317 |
| Headers | show |
| Series | [FFmpeg-devel,1/4] tools/target_dec_fuzzer: Adjust the threshold for VP3 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | fail | Make fate failed |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | warning | Make fate failed |
On Tue, Jul 20, 2021 at 10:29:42PM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: 35877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TARGA_fuzzer-5407292819374080 > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/targa.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) will apply [...]
Please do not apply, This actually changes output to nothing.
On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote:
> Please do not apply, This actually changes output to nothing.
Do you have such a TGA file without an image in it?
thx
[...]
On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > Please do not apply, This actually changes output to nothing. > > Do you have such a TGA file without an image in it? > > Why would that be relevant, comply with TGA specifications please. thx > > [...] > > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have never wished to cater to the crowd; for what I know they do not > approve, and what they approve I do not know. -- Epicurus > _______________________________________________ > 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". >
On Fri, Sep 17, 2021 at 08:06:48PM +0200, Paul B Mahol wrote: > On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > > Please do not apply, This actually changes output to nothing. > > > > Do you have such a TGA file without an image in it? > > > > Why would that be relevant, comply with TGA specifications please. > > thx It is relevant as it would allow to check how such a file is handled by various implementations The specification does not specify that. It just says "No image Data included" and our decoder returns a black image, the specification doesnt say that means "black image" or i missed it when reading after the patch the decoder returns nothing instead of a black image The other type this might reach is type 8, the specification i have doesnt say anything about type 8 except that its reserved Truevision TGAa FILE FORMAT SPECIFICATION Version 2.0 ... Image Type - Field 3 (1 byte): The TGA File Format can be used to store Pseudo-Color, True-Color and Direct-Color images of various pixel depths. Truevision has currently defined seven image types: image Description Type 0 No image Data included [...]
On Sat, Sep 18, 2021 at 06:27:15PM +0200, Michael Niedermayer wrote: > On Fri, Sep 17, 2021 at 08:06:48PM +0200, Paul B Mahol wrote: > > On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer <michael@niedermayer.cc> > > wrote: > > > > > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > > > Please do not apply, This actually changes output to nothing. > > > > > > Do you have such a TGA file without an image in it? > > > > > > Why would that be relevant, comply with TGA specifications please. > > > > thx > > It is relevant as it would allow to check how such a file is handled > by various implementations > The specification does not specify that. It just says > "No image Data included" > and our decoder returns a black image, the specification doesnt say that > means "black image" or i missed it when reading > after the patch the decoder returns nothing instead of a black image > The other type this might reach is type 8, the specification i have doesnt > say anything about type 8 except that its reserved > > Truevision TGAa > FILE FORMAT SPECIFICATION > Version 2.0 > ... > Image Type - Field 3 (1 byte): > The TGA File Format can be used to store Pseudo-Color, True-Color and Direct-Color images of various > pixel depths. Truevision has currently defined seven image types: > image Description > Type 0 No image Data included ping what do you prefer for this issue ? Id like to do something here not just ignore it even if the conclusion is that this is "not a bug but intended behavior" thx [...]
Quoting Michael Niedermayer (2021-12-03 15:04:47) > On Sat, Sep 18, 2021 at 06:27:15PM +0200, Michael Niedermayer wrote: > > On Fri, Sep 17, 2021 at 08:06:48PM +0200, Paul B Mahol wrote: > > > On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer <michael@niedermayer.cc> > > > wrote: > > > > > > > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > > > > Please do not apply, This actually changes output to nothing. > > > > > > > > Do you have such a TGA file without an image in it? > > > > > > > > Why would that be relevant, comply with TGA specifications please. > > > > > > thx > > > > It is relevant as it would allow to check how such a file is handled > > by various implementations > > The specification does not specify that. It just says > > "No image Data included" > > and our decoder returns a black image, the specification doesnt say that > > means "black image" or i missed it when reading > > after the patch the decoder returns nothing instead of a black image > > The other type this might reach is type 8, the specification i have doesnt > > say anything about type 8 except that its reserved > > > > Truevision TGAa > > FILE FORMAT SPECIFICATION > > Version 2.0 > > ... > > Image Type - Field 3 (1 byte): > > The TGA File Format can be used to store Pseudo-Color, True-Color and Direct-Color images of various > > pixel depths. Truevision has currently defined seven image types: > > image Description > > Type 0 No image Data included > > ping > what do you prefer for this issue ? > Id like to do something here not just ignore it even if the conclusion is > that this is "not a bug but intended behavior" A brief look at other opensource decoders suggest they don't support type==0 at all. image-rs does, but it's not clear to be what its output is. I'd say not returning a frame is reasonable.
On Mon, Dec 06, 2021 at 10:58:31AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2021-12-03 15:04:47) > > On Sat, Sep 18, 2021 at 06:27:15PM +0200, Michael Niedermayer wrote: > > > On Fri, Sep 17, 2021 at 08:06:48PM +0200, Paul B Mahol wrote: > > > > On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer <michael@niedermayer.cc> > > > > wrote: > > > > > > > > > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > > > > > Please do not apply, This actually changes output to nothing. > > > > > > > > > > Do you have such a TGA file without an image in it? > > > > > > > > > > Why would that be relevant, comply with TGA specifications please. > > > > > > > > thx > > > > > > It is relevant as it would allow to check how such a file is handled > > > by various implementations > > > The specification does not specify that. It just says > > > "No image Data included" > > > and our decoder returns a black image, the specification doesnt say that > > > means "black image" or i missed it when reading > > > after the patch the decoder returns nothing instead of a black image > > > The other type this might reach is type 8, the specification i have doesnt > > > say anything about type 8 except that its reserved > > > > > > Truevision TGAa > > > FILE FORMAT SPECIFICATION > > > Version 2.0 > > > ... > > > Image Type - Field 3 (1 byte): > > > The TGA File Format can be used to store Pseudo-Color, True-Color and Direct-Color images of various > > > pixel depths. Truevision has currently defined seven image types: > > > image Description > > > Type 0 No image Data included > > > > ping > > what do you prefer for this issue ? > > Id like to do something here not just ignore it even if the conclusion is > > that this is "not a bug but intended behavior" > > A brief look at other opensource decoders suggest they don't support > type==0 at all. image-rs does, but it's not clear to be what its output > is. I'd say not returning a frame is reasonable. ok, will apply thx [...]
NACK On Thu, Dec 9, 2021 at 1:23 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Dec 06, 2021 at 10:58:31AM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2021-12-03 15:04:47) > > > On Sat, Sep 18, 2021 at 06:27:15PM +0200, Michael Niedermayer wrote: > > > > On Fri, Sep 17, 2021 at 08:06:48PM +0200, Paul B Mahol wrote: > > > > > On Fri, Sep 17, 2021 at 8:00 PM Michael Niedermayer < > michael@niedermayer.cc> > > > > > wrote: > > > > > > > > > > > On Fri, Sep 17, 2021 at 07:35:32PM +0200, Paul B Mahol wrote: > > > > > > > Please do not apply, This actually changes output to nothing. > > > > > > > > > > > > Do you have such a TGA file without an image in it? > > > > > > > > > > > > Why would that be relevant, comply with TGA specifications > please. > > > > > > > > > > thx > > > > > > > > It is relevant as it would allow to check how such a file is handled > > > > by various implementations > > > > The specification does not specify that. It just says > > > > "No image Data included" > > > > and our decoder returns a black image, the specification doesnt say > that > > > > means "black image" or i missed it when reading > > > > after the patch the decoder returns nothing instead of a black image > > > > The other type this might reach is type 8, the specification i have > doesnt > > > > say anything about type 8 except that its reserved > > > > > > > > Truevision TGAa > > > > FILE FORMAT SPECIFICATION > > > > Version 2.0 > > > > ... > > > > Image Type - Field 3 (1 byte): > > > > The TGA File Format can be used to store Pseudo-Color, True-Color > and Direct-Color images of various > > > > pixel depths. Truevision has currently defined seven image types: > > > > image Description > > > > Type 0 No image Data included > > > > > > ping > > > what do you prefer for this issue ? > > > Id like to do something here not just ignore it even if the conclusion > is > > > that this is "not a bug but intended behavior" > > > > A brief look at other opensource decoders suggest they don't support > > type==0 at all. image-rs does, but it's not clear to be what its output > > is. I'd say not returning a frame is reasonable. > > ok, will apply > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The greatest way to live with honor in this world is to be what we pretend > to be. -- Socrates > _______________________________________________ > 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". >
diff --git a/libavcodec/targa.c b/libavcodec/targa.c index 3502636c16..221fcc956d 100644 --- a/libavcodec/targa.c +++ b/libavcodec/targa.c @@ -176,6 +176,10 @@ static int decode_frame(AVCodecContext *avctx, if ((ret = ff_set_dimensions(avctx, w, h)) < 0) return ret; + if ((compr & (~TGA_RLE)) == TGA_NODATA) { + return avpkt->size; + } + if ((ret = ff_get_buffer(avctx, p, 0)) < 0) return ret; p->pict_type = AV_PICTURE_TYPE_I; @@ -242,9 +246,6 @@ static int decode_frame(AVCodecContext *avctx, } } - if ((compr & (~TGA_RLE)) == TGA_NODATA) { - memset(p->data[0], 0, p->linesize[0] * h); - } else { if (compr & TGA_RLE) { int res = targa_decode_rle(avctx, s, dst, w, h, stride, bpp, interleave); if (res < 0) @@ -289,7 +290,6 @@ static int decode_frame(AVCodecContext *avctx, } } } - } *got_frame = 1;
Fixes: Timeout Fixes: 35877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TARGA_fuzzer-5407292819374080 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavcodec/targa.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)