[FFmpeg-devel] [PATCH] alac: validate k before using show_bits in decode_scalar

[Michael Niedermayer]

On Thu, Apr 23, 2015 at 08:53:29PM +0200, Andreas Cadhalpun wrote:
> On 23.04.2015 16:37, Michael Niedermayer wrote:
> > On Wed, Apr 22, 2015 at 06:24:54PM +0200, Andreas Cadhalpun wrote:
> >> The k != 1 case calls show_bits(gb, k), which doesn't make sense if k
> >> is 0.
> > 
> > i dont think k = 0 is allowed
> > i suggest you check rice_limit when it is set, i assume that is the
> > source of k=0
> > asking for a sample with rice_limit=0 if it occurs is also a good idea
> 
> OK, new patch attached.
> 
> Best regards,
> Andreas
> 

>  alac.c |    4 ++++
>  1 file changed, 4 insertions(+)
> d364bcf9db9c6dab0584a27026fe36354c5b7c05  0001-alac-reject-rice_limit-0.patch
> From d539a0e3abdffe415553c8e39e22268b01c13187 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun <Andreas.Cadhalpun at googlemail.com>
> Date: Thu, 23 Apr 2015 20:51:03 +0200
> Subject: [PATCH] alac: reject rice_limit 0
> 
> If rice_limit is 0, k can be 0 in decode_scalar, which calls show_bits(gb, k).
> 
> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun at googlemail.com>
> ---
>  libavcodec/alac.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> index ffd2d77..16d56a7 100644
> --- a/libavcodec/alac.c
> +++ b/libavcodec/alac.c
> @@ -569,6 +569,10 @@ static int alac_set_info(ALACContext *alac)
>      alac->rice_history_mult    = bytestream2_get_byteu(&gb);
>      alac->rice_initial_history = bytestream2_get_byteu(&gb);
>      alac->rice_limit           = bytestream2_get_byteu(&gb);
> +    if (!alac->rice_limit) {
> +        avpriv_request_sample(alac->avctx, "Rice limit 0");
> +        return AVERROR(ENOSYS);
> +    }

this doesnt work as our encoder uses a rice_limit of 0 when
compression is disabled
moving the check into if(is_compressed) should work hopefully

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150423/32b015d7/attachment.asc>