← Back to team overview

touch-packages team mailing list archive

[Bug 980963] Re: Heap-based Buffer Overflow in libavcodec

 

lucid has seen the end of its life and is no longer receiving any
updates. Marking the lucid task for this ticket as "Won't Fix".

** Changed in: ffmpeg (Ubuntu Lucid)
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libav in Ubuntu.
https://bugs.launchpad.net/bugs/980963

Title:
  Heap-based Buffer Overflow in libavcodec

Status in ffmpeg package in Ubuntu:
  Invalid
Status in libav package in Ubuntu:
  Fix Released
Status in ffmpeg source package in Lucid:
  Won't Fix
Status in libav source package in Lucid:
  Invalid
Status in ffmpeg source package in Natty:
  Invalid
Status in libav source package in Natty:
  Won't Fix
Status in ffmpeg source package in Oneiric:
  Invalid
Status in libav source package in Oneiric:
  Won't Fix
Status in ffmpeg source package in Precise:
  Invalid
Status in libav source package in Precise:
  Triaged
Status in ffmpeg source package in Quantal:
  Invalid
Status in libav source package in Quantal:
  Fix Released

Bug description:
  A vulnerability in the decoder for VQA media files exists in function
  vqa_decode_chunk (libavcodec/vqavideo.c) of libavcodec (part of
  FFmpeg). This vulnerability allows memory on the heap to be corrupted
  and possibly leads o arbitrary code execution.

  Here's the relevant excerpt from vqa_decode_chunk:

  1 int lobytes = 0;
  2 int hibytes = s->decode_buffer_size / 2;
  3 ...
  4 for (y = 0; y < s->frame.linesize[0] * s->height;
  5   y += s->frame.linesize[0] * s->vector_height) {
  6
  7   for (x = y; x < y + s->width; x += 4, lobytes++, hibytes++) {
  8        pixel_ptr = x;
  9       /* get the vector index, the method for which varies according to
  10          * VQA file version */
  11        switch (s->vqa_version) {
  12        case 1:
  13          ...
  14        case 2:
  15            lobyte = s->decode_buffer[lobytes];
  16            hibyte = s->decode_buffer[hibytes];
  17            vector_index = (hibyte << 8) | lobyte;
  18            vector_index <<= index_shift;
  19            lines = s->vector_height;
  20            break;
  21
  22        case 3:
  23          ...
  24       }
  25        while (lines--) {
  26           s->frame.data[0][pixel_ptr + 0] = s->codebook[vector_index++];
  27           s->frame.data[0][pixel_ptr + 1] = s->codebook[vector_index++];
  28            s->frame.data[0][pixel_ptr + 2] = s->codebook[vector_index++];
  29           s->frame.data[0][pixel_ptr + 3] = s->codebook[vector_index++];
  30            pixel_ptr += s->frame.linesize[0];
  31        }
  32    }
  33 }

  This function fills the pixel buffer (s->frame.data[0]) in tiles of
  4x4 pixels on lines 25 to 30. The problem is that a check to verify
  that the index still addresses a location inside the buffer is
  performed only by the conditions of the for-loops on line 4 and 7,
  however, for the inner while-loop starting on line 25, no such check
  exists. In consequence, up to three extra lines can be written beyond
  the end of the buffer.

  A sample file has been attached, which causes a crash on Ubuntu 11.10
  (32 bit) when played with mplayer. We hope this information is useful
  to you.

  
  Fabian Yamaguchi - University of Goettingen
  Markus Lottmann - Technische Universitaet Berlin

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/980963/+subscriptions