FreeTDS Development Group

[Dennis Nicklaus <nicklaus AT crusher.fnal.gov>]

I had written:

>> varbin->len = colsize; 
>> crashes because varbin->len isn't word aligned, it is offset by
>> that column_offset=1.

Brian responded:

>I had thought we had caught all of those. Although looking
>at mem.c (line 97) it should be working. Are you using 0.50 or the CVS
>version?

I had been using version 0.50. Now that I'm able to get the cvs version,
I see that fix in mem.c should indeed solve that problem. Thanks.
sorry to bring up a solved problem.


I had also written:
>> which increases row_size to 132. Then it calls tds_alloc_row()
>> which will malloc 132 bytes. 
>> Now, when we call dbnextrow, look again at the code with the "varbin"
>>variable
>> in tds_process_row(). If I really have 128 bytes of data in this row, it
>> is going to overflow the malloced area.
>>

Brian responded:
>space in the row buffer is allocated for the maximum size, if you have
>varchar(255) and the data is 1 byte long you get 255 reserved in the row
>buffer.


I still think there might a buffer overflow problem here in combination with
the SYBVARBINARY data with some tds versions.

It appears that things will happen to work at tds version 4.2 because the
line in token.c  tds_process_col_info ( ) :
                info->row_size += curcol->column_size + 1;
has that extra +1 on it. That coupled with the "remainder =row_size %align"
check will get the extra word allocated (in my 128 byte rowsize
example, it will malloc 136 bytes) (4 bytes column_offset + 128 bytes data +
4 bytes extra which happen to be needed because of the length put into the
"varbin" data structure later.)

BUT note that the "remainder =row_size %align" check is inside
 "if (IS_TDS42(tds)) {"

Because of that, it appears to me that at other TDS Versions, (4.6, 5.0?)
things will overflow the malloced buffer because it'll only malloc
133 bytes instead of 136. According to the comments other TDS versions
aren't supposed to use that tds_process_col_info() function. If that's true,
I guess everything is OK.  

Thanks,


Dennis Nicklaus nicklaus AT fnal.gov