Possible buffer overflow in `_WCSCPY`

[matthew-wozniczka]

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:

iODBC/iodbcinst/unicode.c

Line 2171 in ca979a8

_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

iODBC/iodbcinst/unicode.c

Line 2186 in ca979a8

*u2dst = 0;

&

iODBC/iodbcinst/unicode.c

Line 2191 in ca979a8

*u4dst = 0;

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?

[pkleef]

Development is investigating this issue.

[matthew-wozniczka]

FYI, I've just figured out that our test app is being statically-linked against iODBC 3.52.8, so the test failure we're seeing is (almost certainly) actually related to some known issues from the older version of the DM (even though we were providing a newer library at runtime, THAT was fun to debug), and not the overflow I reported (though it still seems like something which should be fixed for its own sake)