similar to: [PATCH] src/libFLAC/stream_decoder.c : Rework fix for seeking bug.

On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote: > But, as we have seen with unusual data the residual signal can be > wider than bps. The FLAC format specification doesn't seem to mention > this. Should it be treated as a valid FLAC stream? I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

Miroslav Lichvar wrote: > I'm trying to figure out how this one works. It seems the problem is > integer underflow in the "frame.header.blocksize-order" expression > used in read_subframe_fixed_() and read_subframe_lpc_() to get the > number of encoded samples, which causes a buffer overflow in the > LPC/fixed subframe decoding. > > The fix prevents that by

On 25.11.2014 12:14, Miroslav Lichvar wrote: > I think the case with non-zero partition order may need to be fixed > too. For example, with partition order of 1, predictor order of 16 and > blocksize of 4, the function would return true and blocksize-order in > the caller would still underflow. > > --- a/src/libFLAC/stream_decoder.c > +++ b/src/libFLAC/stream_decoder.c > @@

On Tue, Nov 25, 2014 at 12:29:33AM -0800, Erik de Castro Lopo wrote: > Google Security Team member, Michele Spagnuolo, recently found two potential > problems in the FLAC code base. They are : > > > CVE-2014-9028 : Heap buffer write overflow > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one

On 9.12.2014 20:33, Tristan Matthews wrote: > On Tue, Dec 9, 2014 at 1:31 PM, Janne Hyv?rinen <cse at sci.fi > <mailto:cse at sci.fi>> wrote: > > On 25.11.2014 12:14, Miroslav Lichvar wrote: > > I think the case with non-zero partition order may need to be fixed > > too. For example, with partition order of 1, predictor order of > 16 and >

On 9.12.2014 20:31, Janne Hyv?rinen wrote: > On 25.11.2014 12:14, Miroslav Lichvar wrote: >> I think the case with non-zero partition order may need to be fixed >> too. For example, with partition order of 1, predictor order of 16 and >> blocksize of 4, the function would return true and blocksize-order in >> the caller would still underflow. >> >> ---

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote: > There have been reports of -9 using huge amounts of memory. -9 is really > theoretical, but people always seem to want to try the max setting. Anyway, > that's not an excuse but figuring out why -9 is using so much memory is lower > on my list than other stuff. -8 should get within 0.01% of -9 and is pretty >

OK, back to this one... --- Josh Coalson <xflac@yahoo.com> wrote: > --- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote: > > The FLAC__stream_decoder_flush doesn't change the state, but when I > > play a > > stream and reach the end I have to do a FLAC__stream_decoder_reset > > and reread > > the metadata instead of simply a FLAC__stream_decoder_flush.

Hi Josh, As you know, I'm writing a FLAC ACM codec using libFLAC. The Audio Codec Manager sends messages to the driver with blocks of data to be converted. I think it will be much easier to decode the data if we could use FLAC__stream_decoder_process_whole_stream() to process the first message, not processing any data that don't make a whole frame, and then use

--- Daniel Souza <danielrsouza@hotmail.com> wrote: > Hi Josh, > > As you know, I'm writing a FLAC ACM codec using libFLAC. The Audio > Codec > Manager sends messages to the driver with blocks of data to be > converted. I > think it will be much easier to decode the data if we could use > FLAC__stream_decoder_process_whole_stream() to process the first >

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

Hi, The FLAC__stream_decoder_flush doesn't change the state, but when I play a stream and reach the end I have to do a FLAC__stream_decoder_reset and reread the metadata instead of simply a FLAC__stream_decoder_flush. This is because the stream state, which indicates the end of the stream, is not changed. Is there a reason, for the state not being reset to

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

Hello, my FLAC plugin to VDR is now running, but the decoder runs into an endless loop at the end of the song. Usually, blocks of 4608 samples are decoded, the last block only has 2220, so I assume this is really the end of the file: Samples decoded: 2220, current time: 292290, bits per sample: 16 Obtaining the decoder states after decoding this last block still looks like decoding should go