On 01/06/2012 01:52 PM, Reinhard Tartler wrote:
> On Fri, Jan 6, 2012 at 12:02 AM, Jason Garrett-Glaser <ja...@x264.com> wrote:
>> On Thu, Jan 5, 2012 at 1:01 PM, Reinhard Tartler <siret...@tauware.de> wrote:
>>> From: Chris Evans <cev...@chromium.org>
>>>
>>> Fixes Bug: #190
>>> Chromium Bug: #100543
>>> Related to CVE-2011-3893
>>>
>>> Signed-off-by: Reinhard Tartler <siret...@tauware.de>
>>> ---
>>> libavcodec/vorbis.c | 6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> I've implemented Ronald's second suggestion.
>>>
>>> diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
>>> index 86df288..66364d1 100644
>>> --- a/libavcodec/vorbis.c
>>> +++ b/libavcodec/vorbis.c
>>> @@ -152,7 +152,7 @@ void ff_vorbis_ready_floor1_list(vorbis_floor1_entry *
>>> list, int values)
>>> }
>>> }
>>>
>>> -static inline void render_line_unrolled(intptr_t x, intptr_t y, int x1,
>>> +static inline void render_line_unrolled(intptr_t x, unsigned char y, int
>>> x1,
>>> intptr_t sy, int ady, int adx,
>>> float *buf)
>>> {
>>> @@ -175,7 +175,7 @@ static inline void render_line_unrolled(intptr_t x,
>>> intptr_t y, int x1,
>>> }
>>> }
>>>
>>> -static void render_line(int x0, int y0, int x1, int y1, float *buf)
>>> +static void render_line(int x0, unsigned char y0, int x1, int y1, float
>>> *buf)
>>> {
>>> int dy = y1 - y0;
>>> int adx = x1 - x0;
>>> @@ -187,7 +187,7 @@ static void render_line(int x0, int y0, int x1, int y1,
>>> float *buf)
>>> } else {
>>> int base = dy / adx;
>>> int x = x0;
>>> - int y = y0;
>>> + unsigned char y = y0;
>>> int err = -adx;
>>> ady -= FFABS(base) * adx;
>>> while (++x < x1) {
>>> --
>>
>> Relying on undefined language behavior to solve a problem is a terrible idea.
>
> What part of the patch is undefined behavior?
I also thought this was undefined or implementation-defined, but after
another look I think it's fine. Whether or not it's "correct" behavior
for Vorbis is unclear, but implicit casting from int to uint8_t seems to
be defined behavior from what i can tell.
So either patch looks ok I suppose.
-Justin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
