[PATCH] d3dxof: avoid some strcpy overflows (Coverity)

Matteo Bruni matteo.mystral at gmail.com
Mon Sep 5 18:41:14 CDT 2016


2016-09-05 9:34 GMT+02:00 Henri Verbeet <hverbeet at gmail.com>:
> On 4 September 2016 at 11:24, Marcus Meissner <marcus at jet.franken.de> wrote:
>> @@ -532,8 +532,11 @@ static BOOL is_name(parse_buffer* buf)
>>    buf->rem_bytes -= pos;
>>
>>    TRACE("Found name %s\n", tmp);
>> +  if (strlen(tmp)+1 > sizeof(buf->value)) {
>> +    FIXME("name %s exceeds buffer length\n", tmp);
>> +    return FALSE;
>> +  }
>>    strcpy((char*)buf->value, tmp);
>> -
>>    return TRUE;
>>  }
> There are plenty of things wrong with d3dxof, but assuming the
> preceding code isn't too broken, I don't think this can happen. You
> should probably just get rid of the "tmp" buffer and use read_bytes()
> or something similar after calculating "pos" though. (The TRACE can
> use debugstr_an().) That probably applies to is_string() as well.

Hmm, unless there is something guaranteeing that the name can't be
longer than 100 bytes (and there might be, I haven't looked too
deeply) a check is still needed. Totally agree with the rest here and
below, though.

>> @@ -928,6 +937,10 @@ static BOOL parse_template_option_info(parse_buffer * buf)
>>      {
>>        if (get_TOKEN(buf) != TOKEN_NAME)
>>          return FALSE;
>> +      if (strlen((char*)buf->value)+1 > sizeof(cur_template->children[cur_template->nb_children])) {
>> +        FIXME("name %s too long for buffer\n", (char*)buf->value);
>> +        return FALSE;
>> +      }
>>        strcpy(cur_template->children[cur_template->nb_children], (char*)buf->value);
> Once you've calculated to number of bytes you need to copy anyway, you
> might as well just use memcpy(). I.e., strcpy() is almost always the
> wrong choice, for one reason or another.

FWIW that part also doesn't check if it's overrunning the array on the
other dimension i.e. that nb_children is less than MAX_CHILDREN. Not
that other parts of the code do check for it... The only time that's
checked in parsing.c is at the end of parse_object_parts() and that's
after the fact :/
I guess fixing that should be a separate patch anyway.



More information about the wine-devel mailing list