I'm investigating a test failure which involves iODBC 3.52.16 where a column which is fetched in parts via SQLGetData is only returning the data from the first call on AIX (Don't have visibility yet into exactly what's going on, am going to need to set up access to an AIX machine & wrassle w/ their terrible debugger), but not on other platforms (Linux, Darwin), or with UnixODBC (though a similar issue was occurring with an older version of iODBC on all platforms, I theorized due to some bugs related to WCHAR conversions which had since been fixed)
In any case, was reading through the source, and I think I found a possible buffer overflow in the _WCSCPY utility function:
|
_WCSCPY(IODBC_CHARSET charset, void *dest, void *sour) |
The issue I see is that if the output buffer is allocated with a size to exactly hold the (null-terminated) string, the
&
statements would be writing right past the end of the buffer, since the
++ in the
while loop has already moved the output pointer past the
actual null-terminator
It's probably not the cause of my issue, given how reliably it seems to fail without other symptoms, but it's UB, so maybe?
I'm investigating a test failure which involves iODBC 3.52.16 where a column which is fetched in parts via
SQLGetDatais only returning the data from the first call on AIX (Don't have visibility yet into exactly what's going on, am going to need to set up access to an AIX machine & wrassle w/ their terrible debugger), but not on other platforms (Linux, Darwin), or with UnixODBC (though a similar issue was occurring with an older version of iODBC on all platforms, I theorized due to some bugs related to WCHAR conversions which had since been fixed)In any case, was reading through the source, and I think I found a possible buffer overflow in the
_WCSCPYutility function:iODBC/iodbcinst/unicode.c
Line 2171 in ca979a8
The issue I see is that if the output buffer is allocated with a size to exactly hold the (null-terminated) string, the
iODBC/iodbcinst/unicode.c
Line 2186 in ca979a8
iODBC/iodbcinst/unicode.c
Line 2191 in ca979a8
++in thewhileloop has already moved the output pointer past the actual null-terminatorIt's probably not the cause of my issue, given how reliably it seems to fail without other symptoms, but it's UB, so maybe?