On Wed, Nov 11, 2015 at 8:29 PM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > On 11.11.2015 12:28, Vittorio Giovara wrote: >> On Wed, Nov 11, 2015 at 1:16 AM, Andreas Cadhalpun >> <andreas.cadhal...@googlemail.com> wrote: >>> Otherwise it causes a NULL pointer dereference of frame->data[1]. >>> >>> Signed-off-by: Andreas Cadhalpun <andreas.cadhal...@googlemail.com> >>> --- >>> libavcodec/dds.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/libavcodec/dds.c b/libavcodec/dds.c >>> index c918cf0..fe36709 100644 >>> --- a/libavcodec/dds.c >>> +++ b/libavcodec/dds.c >>> @@ -662,6 +662,11 @@ static int dds_decode(AVCodecContext *avctx, void >>> *data, >>> >>> if (ctx->paletted) { >>> int i; >>> + if (!frame->data[1]) { >>> + av_log(avctx, AV_LOG_ERROR, >>> + "Palette frame buffer is not allocated.\n"); >>> + return AVERROR_INVALIDDATA; >>> + } >>> /* Use the first 1024 bytes as palette, then copy the rest. */ >>> bytestream2_get_buffer(gbc, frame->data[1], 256 * 4); >>> for (i = 0; i < 256; i++) >> >> how can this happen? > > That's best described with code: > if (!ctx->compressed && ctx->paletted && > !(av_pix_fmt_desc_get(avctx->pix_fmt)->flags & (AV_PIX_FMT_FLAG_PAL | > AV_PIX_FMT_FLAG_PSEUDOPAL))) > > Attached is a patch using this expression to check for the problem.
Sorry, I wasn't clear with my question. What I meant is that in video_get_buffer() (frame.c) explicitly allocates data[1] when any pixel format with AV_PIX_FMT_FLAG_PAL is requested, and in dds when (ctx->paletted) is set, then AV_PIX_FMT_PAL8 is the pixel format chosen every time. So unless I'm missing something data[1] is always allocated, no? -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel