| Bug #31055 | Uninitiated memory returned by SQLGetFunctions() with SQL_API_ODBC3_ALL_FUNCTION | ||
|---|---|---|---|
| Submitted: | 17 Sep 2007 12:18 | Modified: | 12 Oct 2007 13:09 |
| Reporter: | Kent Boortz | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S2 (Serious) |
| Version: | 3.51.20 | OS: | Any |
| Assigned to: | Kent Boortz | CPU Architecture: | Any |
[19 Sep 2007 15:39]
Kent Boortz
When SQLGetFunctions() returns an vector, the vector is now cleared before positions are set, avoiding potentially returning random uninitiated data.
[19 Sep 2007 15:40]
Kent Boortz
This will be in 3.51.21
[12 Oct 2007 13:09]
MC Brown
A note has been added to the 3.51.21 changelog: Uninitiated memory could be used when C/ODBC internally calls SQLGetFunctions().
Description: In some situations unixODBC calls the driver SQLGetFunctions() with the flag SQL_API_ODBC3_ALL_FUNCTIONS. The driver will fill in a bitmap array and return to the manager. But the driver code assumes the manager has cleared the memory in the array, and unixODBC 2.2.12 assumes the driver will. Valgrind complains about this. How to repeat: Run the test case "my_bulk" under valgrind, or run the test using GDB and set a breakpoint at '__connect_part_two' in unixODBC, and watch what happens to the variable 'supported_funcs'. Suggested fix: @@ -1232,6 +1235,14 @@ myodbc_func_size= sizeof(myodbc3_functions) / sizeof(myodbc3_functions[0]); + if (fFunction == SQL_API_ODBC3_ALL_FUNCTIONS || + fFunction == SQL_API_ALL_FUNCTIONS) + { + /* Clear the bit array or SQLUSMALLINT array, same size */ + memset(pfExists, 0, + sizeof(SQLUSMALLINT) * SQL_API_ODBC3_ALL_FUNCTIONS_SIZE); + } + if (fFunction == SQL_API_ODBC3_ALL_FUNCTIONS) { for (index= 0; index < myodbc_func_size; index++)