[FFmpeg-devel] [PATCH] avcodec/h264_mb: Fix undefined shifts

Michael Niedermayer michaelni at gmx.at
Thu Mar 12 16:29:32 CET 2015


On Thu, Mar 12, 2015 at 04:17:30PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 12, 2015 at 03:39:51PM +0100, Christophe Gisquet wrote:
> > Hi,
> > 
> > 2015-03-12 14:37 GMT+01:00 Michael Niedermayer <michaelni at gmx.at>:
> > >> >      const int mx      = h->mv_cache[list][scan8[n]][0] + src_x_offset * 8;
> > >> >      int my            = h->mv_cache[list][scan8[n]][1] + src_y_offset * 8;
> > >> >      const int luma_xy = (mx & 3) + ((my & 3) << 2);
> > >> > -    ptrdiff_t offset  = ((mx >> 2) << pixel_shift) + (my >> 2) *
> > >> > h->mb_linesize;
> > >> > +    ptrdiff_t offset  = (mx >> 2) * (1 << pixel_shift) + (my >> 2) *
> > >> > h->mb_linesize;
> > >>
> > >>
> > >> Why is this undefined?
> > >
> > > Because C sucks
> > 
> > I actually have an equivalent question to Ronald's. Is there a valid
> > input that causes the undefined behaviour? For an invalid input (e.g.
> > DoS tentative), is the behaviour worsened?
> 
> i belive any motion vector that points left outside the picture will
> trigger this one, its also happening with multiple fate samples
> This issue is about undefined behavor according to the C specification
> not about current gcc generating actually bad code from it AFAIK

also a compiler could very easily generate bad code from this, that
is it would be both allowed in C and make sense for it to do so
consider
((mx >> 2) << pixel_shift)
...
const int full_mx    = mx >> 2;
....
if (full_mx                <          0 - extra_width  ||


from "(mx >> 2) << pixel_shift)" a compiler could imply that
(mx >> 2) is >= 0 as the alterantive is undefined
that makes full_mx >= 0
at this point the only way for full_mx < - extra_width is a non
zero extra_width and that is impossible on the else path to
"if (mx & 7)" above so the compiler could optimize this check out
in that case

luckily gcc is not smart enough to do that

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20150312/06495e19/attachment.asc>


More information about the ffmpeg-devel mailing list