Buffer Overflow ?
camber at ais.org
Fri Jan 26 01:05:13 EST 2001
Whoever (don't think it was me...the variable names aren't my style)
wrote this should have used TDS_INT and TDS_FLOAT...that will resolve the
problem once I make the changes mentioned in my other email.
On Thu, 25 Jan 2001, Steve Langasek wrote:
> Hi Brian,
> On Wed, 24 Jan 2001, Brian Bruns wrote:
> > Technically it is defined by the API as length of dest, I don't have the
> > doc in front of me but I believe it is something like 'size of buffer
> > into which the data will be copied' (remember that tds_convert is called
> > by dbconvert, ct_convert and implicitly by binding a to a different type).
> > So there is an off by one error, and I'll apply the patch.
> At the bottom is a patch that addresses all of the off-by-one errors I found
> in tds/convert.c. In addition, it ensures that all SYBTEXT and SYBCHAR
> targets are null-terminated strings, which if I understand correctly is the
> proper behavior.
> I also noticed these lines during the process:
> TDS_INT tds_convert_money(int srctype,unsigned char *src,
> int desttype,unsigned char *dest,TDS_INT destlen)
> long high;
> unsigned long low;
> double dmoney;
> case SYBFLT8:
> /* Used memcpy to avoid alignment/bus errors */
> memcpy(&high, src, 4);
> memcpy(&low, src+4, 4);
> dmoney = (double)high * 65536 * 65536 + (double)low;
> dmoney = dmoney / 10000;
> *(double *)dest = dmoney;
> I don't have a patch for this yet, but just as a heads-up, this behavior is
> not endian-clean on machines with a 64-bit word. Since a long int is 8 bytes
> long on alpha, ppc, etc., these memcpy's only write to the first 4 bytes of
> the long... and those first 4 bytes aren't guaranteed to be the low bytes
> we're looking for.
More information about the FreeTDS