Recent changes to bugs

out of bounds heap read in dirac::VHFilter::Interleave

Hanno Böck — Sat, 01 Jul 2017 21:28:47 -0000

The attached file will cause an out of bounds read in the dirac decoder. This was found with american fuzzy lop.

Stack trace (from asan):

==10450==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62f00000ca00 at pc 0x0000004c36dc bp 0x7ffd5cbcba60 sp 0x7ffd5cbcb210
READ of size 1408 at 0x62f00000ca00 thread T0
    #0 0x4c36db in __asan_memcpy (/r/dirac/dirac_decoder+0x4c36db)
    #1 0x5c4151 in dirac::VHFilter::Interleave(int, int, int, int, dirac::CoeffArray&) /f/dirac-1.0.2/libdirac_common/wavelet_utils.cpp:504:9
    #2 0x5a8106 in dirac::VHFilterLEGALL5_3::Synth(int, int, int, int, dirac::CoeffArray&) /f/dirac-1.0.2/libdirac_common/wavelet_utils.cpp:899:5
    #3 0x59cc61 in dirac::WaveletTransform::Transform(dirac::Direction, dirac::PicArray&, dirac::CoeffArray&) /f/dirac-1.0.2/libdirac_common/wavelet_utils.cpp:473:25
    #4 0x568096 in dirac::PictureDecompressor::Decompress(dirac::ParseUnitByteIO&, dirac::PictureBuffer&) /f/dirac-1.0.2/libdirac_decoder/picture_decompress.cpp:172:24
    #5 0x546ebd in dirac::SequenceDecompressor::DecompressNextPicture(dirac::ParseUnitByteIO*) /f/dirac-1.0.2/libdirac_decoder/seq_decompress.cpp:128:45
    #6 0x5307e6 in dirac::DiracParser::Parse() /f/dirac-1.0.2/libdirac_decoder/dirac_cppparser.cpp:223:54
    #7 0x515963 in dirac_parse /f/dirac-1.0.2/libdirac_decoder/dirac_parser.cpp:334:38
    #8 0x513d17 in DecodeDirac(char const*, char const*) /f/dirac-1.0.2/decoder/decmain.cpp:145:17
    #9 0x513d17 in main /f/dirac-1.0.2/decoder/decmain.cpp:303
    #10 0x7efd923571d0 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24/csu/../csu/libc-start.c:289
    #11 0x41ce29 in _start (/r/dirac/dirac_decoder+0x41ce29)

0x62f00000ca00 is located 0 bytes to the right of 50688-byte region [0x62f000000400,0x62f00000ca00)
allocated by thread T0 here:
    #0 0x50f3b0 in operator new[](unsigned long) (/r/dirac/dirac_decoder+0x50f3b0)
    #1 0x559cd3 in dirac::TwoDArray<int>::Init(int, int) /f/dirac-1.0.2/libdirac_common/../libdirac_common/arrays.h:520:38

#56 heap overflow (write) in dirac::ArithCodecBase::ReadAllData

Hanno Böck — Sat, 01 Jul 2017 21:27:03 -0000

example file attached

heap overflow (write) in dirac::ArithCodecBase::ReadAllData

Hanno Böck — Sat, 01 Jul 2017 21:26:22 -0000

The attached sample file will cause a heap overflow in the dirac decoder. This was found with the help of the fuzzing tool american fuzzy lop.

Here's a stack trace from address sanitizer:

==4153==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000019ef at pc 0x00000056f150 bp 0x7fff5b770e80 sp 0x7fff5b770e78
WRITE of size 1 at 0x6020000019ef thread T0
    #0 0x56f14f in dirac::ArithCodecBase::ReadAllData(int) /f/dirac-1.0.2/libdirac_common/arith_codec.cpp:163:37
    #1 0x56f14f in dirac::ArithCodecBase::InitDecoder(int) /f/dirac-1.0.2/libdirac_common/arith_codec.cpp:134
    #2 0x60548e in dirac::ArithCodec<dirac::CoeffArray>::Decompress(dirac::CoeffArray&, int) /f/dirac-1.0.2/libdirac_decoder/../libdirac_common/arith_codec.h:451:9
    #3 0x60548e in dirac::CompDecompressor::Decompress(dirac::ComponentByteIO*, dirac::CoeffArray&, dirac::SubbandList&) /f/dirac-1.0.2/libdirac_decoder/comp_decompress.cpp:106
    #4 0x568038 in dirac::PictureDecompressor::Decompress(dirac::ParseUnitByteIO&, dirac::PictureBuffer&) /f/dirac-1.0.2/libdirac_decoder/picture_decompress.cpp:170:28
    #5 0x546ebd in dirac::SequenceDecompressor::DecompressNextPicture(dirac::ParseUnitByteIO*) /f/dirac-1.0.2/libdirac_decoder/seq_decompress.cpp:128:45
    #6 0x5307e6 in dirac::DiracParser::Parse() /f/dirac-1.0.2/libdirac_decoder/dirac_cppparser.cpp:223:54
    #7 0x515963 in dirac_parse /f/dirac-1.0.2/libdirac_decoder/dirac_parser.cpp:334:38
    #8 0x513d17 in DecodeDirac(char const*, char const*) /f/dirac-1.0.2/decoder/decmain.cpp:145:17
    #9 0x513d17 in main /f/dirac-1.0.2/decoder/decmain.cpp:303
    #10 0x7f6e7b7bc1d0 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.24-r2/work/glibc-2.24/csu/../csu/libc-start.c:289
    #11 0x41ce29 in _start (/r/dirac/dirac_decoder+0x41ce29)

0x6020000019ef is located 1 bytes to the left of 1-byte region [0x6020000019f0,0x6020000019f1)
allocated by thread T0 here:
    #0 0x50f3b0 in operator new[](unsigned long) (/r/dirac/dirac_decoder+0x50f3b0)
    #1 0x56ee2e in dirac::ArithCodecBase::ReadAllData(int) /f/dirac-1.0.2/libdirac_common/arith_codec.cpp:161:28
    #2 0x56ee2e in dirac::ArithCodecBase::InitDecoder(int) /f/dirac-1.0.2/libdirac_common/arith_codec.cpp:134
    #3 0x568038 in dirac::PictureDecompressor::Decompress(dirac::ParseUnitByteIO&, dirac::PictureBuffer&) /f/dirac-1.0.2/libdirac_decoder/picture_decompress.cpp:170:28
    #4 0x546ebd in dirac::SequenceDecompressor::DecompressNextPicture(dirac::ParseUnitByteIO*) /f/dirac-1.0.2/libdirac_decoder/seq_decompress.cpp:128:45

decmain.cpp: 2 * possible unterminated strings ?

dcb — Sun, 11 May 2014 16:06:41 -0000

[decmain.cpp:122]: (error) Dangerous usage of 'infile_name' (strncpy doesn't always null-terminate it).
[decmain.cpp:128]: (error) Dangerous usage of 'outfile_data' (strncpy doesn't always null-terminate it).

Source code is

strncpy(infile_name, iname, sizeof(infile_name));

strncpy(outfile_data, oname, sizeof(outfile_data));

if ((ifp = fopen (infile_name, "rb")) ==NULL)
{
    perror(iname);
    return;
}

if ((fpdata = fopen (outfile_data, "wb")) ==NULL)

Suggest properly terminate the two strings before calling fopen.

invalid invocation of `cp` when build docs on Mac OS X

Tue, 24 Jan 2012 04:32:33 -0000

The BSD cp command (or at least, the one included with Mac OS X) does not support the '-d' option; the documentation Makefile tries to do this anyway and so the build fails.

Using just `cp -R` rather than `cd -dR` works fine.

Dirac-1.0.2 quant_chooser.cpp fails with gcc45

Dave Plater — Fri, 09 Apr 2010 06:12:12 -0000

I maintain dirac in openSUSE and it fails on :-
quant_chooser.cpp: In member function 'void dirac::QuantChooser::SetSkip(dirac::CodeBlock&, int)':
quant_chooser.cpp:343:49: error: invalid operands of types '__gnu_cxx::__enable_if<true, double>::__type' and 'int' to binary'operator<<'
in line 343 where [i] is column 49 :-
if ( (std::abs(m_coeff_data[j][i])<<2) >= u_threshold )
can_skip = false;
In function :-
void QuantChooser::SetSkip( CodeBlock& cblock , const int qidx)
{
const int u_threshold = dirac_quantiser_lists.QuantFactor4( qidx );
// Sets the skip flag for a codeblock
bool can_skip = true;
for (int j=cblock.Ystart(); j<cblock.Yend(); ++j )
{
for (int i=cblock.Xstart(); i<cblock.Xend(); ++i )
{
if ( (std::abs(m_coeff_data[j][i])<<2) >= u_threshold )
can_skip = false;
} }
cblock.SetSkip( can_skip );
}
> and also :-
> quant_chooser.cpp: In member function 'dirac::CoeffType> dirac::QuantChooser::BlockAbsMax(const dirac::Subband&)':
> quant_chooser.cpp:358:64: error: no matching function for call to
> 'max(int&, __gnu_cxx::__enable_if<true, double>::__type)'
> In line 358 where the last ) before ; is column 64:-
> val = std::max( val , std::abs(m_coeff_data[j][i]) );
> In function
> CoeffType QuantChooser::BlockAbsMax( const Subband& node )
> {
> int val( 0 );
>
> for (int j=node.Yp() ; j<node.Yp()+node.Yl(); ++j)
> {
> for (int i=node.Xp() ; i<node.Xp()+node.Xl(); ++i)
> { val = std::max( val , std::abs(m_coeff_data[j][i]) );
> }// i
> }// j
>
> return val;
> }

The -fpermissive flag doesn't work either but the suse 11.2 version builds with gcc44.

DirectShow Decoder Filter does not display frame-rate

Anonymous — Thu, 23 Apr 2009 22:23:54 -0000

Encode a file using Dirac and store to AVI (ex: MediaCoder).
Use GraphStudio to create a render graph. Right Click on the "Dirac Video Decoder" and look at XForm-In and XForm-Out tabs.
Frame rate information is not propagated from input to output.

SyncToUnitStart pathological condition

soDark6 — Thu, 17 Apr 2008 07:04:24 -0000

In Dirac version 0.9.1

When decoding I frames that are incomplete the module
ParseUnitByteIO::SyncToUnitStart can enter a loop condition from which it never returns.

It appears to be searching for 'BBCD' but never finds
it and never exits the loop. This occurs even though
BBCD is at the start of the frame.

It is possible to force this condition by sending a malformed frame of data to the parser (by dropping or adding a byte). The decoder returns the state STATE_BUFFER indicating it needs more data. When the
next I frame is received (starting BBCD) the decoder
does not recover and enters an endless loop.

Lossless encoding with motion estimation broken

Anonymous — Tue, 04 Mar 2008 07:54:33 -0000

About version 0.9.1.

When ME/MC is enabled, the lossless switch leads to a core dump after a couple of frames. Does not happen with -num_L1 0, i.e. in INTRA coding mode.

Example call:
~/lib/sw/dirac-0.9.1/encoder/dirac_encoder -QCIF -fr 25 -local -verbose -lossless -num_L1 250 -targetrate 64 ~/lib/videos/akiyo_qcif.yuv enc.drc > dirac.log

Reported by till@etill.net.

Dirac encode fail v0.91

Anastasios K — Thu, 14 Feb 2008 01:04:37 -0000

Hello there,

I hope I will not interrupt you.
Could you advice please what is wrong in what I am doing during an encode?
My steps was that:
1) I made 7 BMP files from some DivX video file using VirtualDub to extract them as BMP files.
2) Then I converted them to RGB files using ImageMagick v6.3.7.Q16 with the follow line, for each file:
convert -size 720x480 - depth 8 00x.bmp rgb:00x.rgb
I did that for 7 BMP files, change the x to appropriate numbers.
3) Next step was converting to YUV files using your software which I compile with Visual Studio 2005 Professional. The line was:
rgbtoyuv422 <00x.rgb >00x.yuv 720 480 1
I did that for 7 RGB files, change the x to appropriate numbers.
4) Then I concatinate them to one big file with the following line:
copy *.yuv /b all_in_one.yuv /b
5) Finally I run the encodedirac as it show the attach file, but I receive an error after ~1min.
The line for encode process was:
EncodeDirac -SD480I60 -width 720 -height 480 -fr 29.97 -cformat YUV422P -qf 9 all_in_one.yuv test.drc

So, could you see any mistake in my steps?

Thank you.

Best Regards,
Anastasios