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

[17 Sep 2007 12:18] Kent Boortz
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

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,
+  }
   if (fFunction == SQL_API_ODBC3_ALL_FUNCTIONS)
     for (index= 0; index < myodbc_func_size; index++)
[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().