[PATCH 0/2] MR7013: odbc32: Add null pointer checks.

[Owen Rudge (＠orudge)]

"erwin Data Modeler" crashes under Wine when making ODBC connections (to native ODBC drivers on macOS via iODBC) due to passing in `NULL` values in places. These checks allow execution to proceed successfully.

[PATCH 1/2] odbc32: Avoid crashing if str is null in debugstr_sqlstr.

[Owen Rudge]

From: Owen Rudge

---
 dlls/odbc32/proxyodbc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/odbc32/proxyodbc.c b/dlls/odbc32/proxyodbc.c
index 62c240b6e90..e19fd179bc4 100644
--- a/dlls/odbc32/proxyodbc.c
+++ b/dlls/odbc32/proxyodbc.c
@@ -1068,7 +1068,7 @@ SQLRETURN WINAPI SQLColAttribute(SQLHSTMT StatementHandle, SQLUSMALLINT ColumnNu

static const char *debugstr_sqlstr( const SQLCHAR *str, SQLSMALLINT len )
 {
-    if (len == SQL_NTS) len = strlen( (const char *)str );
+    if (len == SQL_NTS) len = (str == NULL) ? 0 : strlen( (const char *)str );
     return wine_dbgstr_an( (const char *)str, len );
 }

[PATCH 2/2] odbc32: Add null pointer checks to update_result_lengths helpers.

[Owen Rudge]

From: Owen Rudge

---
 dlls/odbc32/proxyodbc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/dlls/odbc32/proxyodbc.c b/dlls/odbc32/proxyodbc.c
index e19fd179bc4..7340cde76ca 100644
--- a/dlls/odbc32/proxyodbc.c
+++ b/dlls/odbc32/proxyodbc.c
@@ -1833,6 +1833,9 @@ SQLRETURN WINAPI SQLExecDirect(SQLHSTMT StatementHandle, SQLCHAR *StatementText,
 static void len_to_user( SQLLEN *ptr, UINT8 *len, UINT row_count, UINT width )
 {
     UINT i;
+
+    if (ptr == NULL || len == NULL) return;
+
     for (i = 0; i < row_count; i++)
     {
         *ptr++ = *(SQLLEN *)(len + i * width);
@@ -1842,6 +1845,9 @@ static void len_to_user( SQLLEN *ptr, UINT8 *len, UINT row_count, UINT width )
 static void len_from_user( UINT8 *len, SQLLEN *ptr, UINT row_count, UINT width )
 {
     UINT i;
+
+    if (ptr == NULL || len == NULL) return;
+
     for (i = 0; i < row_count; i++)
     {
         *(SQLLEN *)(len + i * width) = *ptr++;

[PATCH 2/2] odbc32: Add null pointer checks to update_result_lengths helpers.

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=150374

Your paranoid android.

=== debian11b (64 bit WoW report) ===

dxgi:
dxgi: Timeout

[Fabian Maurer (＠DarkShadow44)]

I'm curious: How does it pass the NULL values in there, shouldn't it be rejected earlier?

[Hans Leidekker (＠hans)]

Hans Leidekker (@hans) commented about dlls/odbc32/proxyodbc.c:
> static void len_to_user( SQLLEN *ptr, UINT8 *len, UINT row_count, UINT width )
>  {
>      UINT i;
> -
> - if (ptr == NULL || len == NULL) return;
> -

len is allocated by us and shouldn't be NULL. Where do you see that being passed?

[Owen Rudge (＠orudge)]

On Mon Dec 16 09:46:12 2024 +0000, Hans Leidekker wrote:
> len is allocated by us and shouldn't be NULL. Where do you see that
> being passed?

Adding in some tracing to the code, it looks like the app is binding 3 columns, but not consecutive columns, and we're crashing when trying to access the first non-bound column:

```
011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870, ColumnNumber 1, TargetType 1, TargetValue 000000001966D770, BufferLength 41, StrLen_or_Ind 000000000572E8D6)
011c:0120:trace:odbc:SQLBindCol Returning 0
011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870, ColumnNumber 2, TargetType 4, TargetValue 000000000572E8EC, BufferLength 4, StrLen_or_Ind 000000000572E900)
011c:0120:trace:odbc:SQLBindCol Returning 0
011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870, ColumnNumber 6, TargetType 1, TargetValue 0000000019542250, BufferLength 21, StrLen_or_Ind 000000000572E92A)
011c:0120:trace:odbc:SQLBindCol Returning 0
011c:0120:trace:odbc:SQLFetch (StatementHandle 00000000196C7870)
011c:0120:trace:odbc:update_result_lengths (sql param output), bind_col count: 6 bind_param count: 0
011c:0120:trace:odbc:len_to_user ptr: 000000000572E8D6 len: 00000000195421C0 row_count: 1 width: 8
011c:0120:trace:odbc:len_to_user ptr: 000000000572E900 len: 0000000019542220 row_count: 1 width: 8
011c:0120:trace:odbc:len_to_user ptr: 0000000000000000 len: 0000000000000000 row_count: 1 width: 8
```

[Hans Leidekker (＠hans)]

On Mon Dec 16 10:14:35 2024 +0000, Owen Rudge wrote:
> Adding in some tracing to the code, it looks like the app is binding 3
> columns, but not consecutive columns, and we're crashing when trying to
> access the first non-bound column:
> 011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870,
> ColumnNumber 1, TargetType 1, TargetValue 000000001966D770, BufferLength
> 41, StrLen_or_Ind 000000000572E8D6)
> 011c:0120:trace:odbc:SQLBindCol Returning 0
> 011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870,
> ColumnNumber 2, TargetType 4, TargetValue 000000000572E8EC, BufferLength
> 4, StrLen_or_Ind 000000000572E900)
> 011c:0120:trace:odbc:SQLBindCol Returning 0
> 011c:0120:trace:odbc:SQLBindCol (StatementHandle 00000000196C7870,
> ColumnNumber 6, TargetType 1, TargetValue 0000000019542250, BufferLength
> 21, StrLen_or_Ind 000000000572E92A)
> 011c:0120:trace:odbc:SQLBindCol Returning 0
> 011c:0120:trace:odbc:SQLFetch (StatementHandle 00000000196C7870)
> 011c:0120:trace:odbc:update_result_lengths (sql param output), bind_col
> count: 6 bind_param count: 0
> 011c:0120:trace:odbc:len_to_user ptr: 000000000572E8D6 len:
> 00000000195421C0 row_count: 1 width: 8
> 011c:0120:trace:odbc:len_to_user ptr: 000000000572E900 len:
> 0000000019542220 row_count: 1 width: 8
> 011c:0120:trace:odbc:len_to_user ptr: 0000000000000000 len:
> 0000000000000000 row_count: 1 width: 8

If SQLBindCol() was never called for a column then ptr will be NULL so checking ptr should be sufficient.