Re: Buffer overrun in III_dequantize_sample

Am Fri, 21 Jul 2017 10:23:45 +0100
schrieb electricworry <[email protected]>: 

> I've been doing some testing of the latest LAME in CVS and there's the
> possibility to cause a buffer overrun in III_dequantize_sample by inputting
> a malformed file. It would appear to not be exploitable, but it should
> probably be fixed.

Is this different from

	https://blogs.gentoo.org/ago/2017/06/17/lame-stack-based-buffer-overflow-in-iii_dequantize_sample-layer3-c

? Do you produce a crash with/without ASan?

> sfreq == 3;
> gr_infos->block_type == 2
> gr_infos->mixed_block_flag is true

I guess that is not the full set of conditions …

> However, there might be additional factors. I have an input file that
> reproduces the issue. Would anyone be able to help me identify the root
> cause?

As mpg123 developer, I am muchly interested in your input file to see
if it also triggers that. The respective code in LAME is a fork of
mpg123 and the fix is likely identical. Can you send the example to
[email protected]? I guess the first n KiB of the file can be enough.

In any case … we should go forward with the plan to remove the decoding
code from lame and install additional hooks in libmpg123 to be able to
build the analyser. The trouble is to define the “we” here.


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev