[FFmpeg-devel] [PATCH] avformat/mov: fix undefined behavior in mov_read_default

[Andreas Rheinhardt]

Zhao Zhili:
> ---
>  libavformat/mov.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index df5bebdff1..da438e4e2c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -6945,13 +6945,12 @@ static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>                    a.type == MKTAG('h','o','o','v')) &&
>                  a.size >= 8 &&
>                  c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
> -                uint8_t buf[8];
> -                uint32_t *type = (uint32_t *)buf + 1;
> -                if (avio_read(pb, buf, 8) != 8)
> -                    return AVERROR_INVALIDDATA;
> +                uint32_t type;
> +                avio_skip(pb, 4);
> +                type = avio_rl32(pb);
>                  avio_seek(pb, -8, SEEK_CUR);
> -                if (*type == MKTAG('m','v','h','d') ||
> -                    *type == MKTAG('c','m','o','v')) {
> +                if (type == MKTAG('m','v','h','d') ||
> +                    type == MKTAG('c','m','o','v')) {
>                      av_log(c->fc, AV_LOG_ERROR, "Detected moov in a free or hoov atom.\n");
>                      a.type = MKTAG('m','o','o','v');
>                  }
> 
1. The undefined behaviour you are talking about is that buf needn't
have the right alignment for an uint32_t, isn't it? This should be
mentioned in the commit message instead of the generic "undefined
behaviour".
2. Your code won't work on big endian.

- Andreas