MySQL Bugs: #119161: ODBC Connector 9.4.0 Access Violation

Bug #119161	ODBC Connector 9.4.0 Access Violation
Submitted:	15 Oct 2025 11:03	Modified:	5 Jan 8:25
Reporter:	Michael Forshaw	Email Updates:
Status:	Open	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	9.4.0	OS:	Windows (Server 2016, 2022)
Assigned to:		CPU Architecture:	x86 (x86-64)

Description:
We have a number of users who upgraded from the MySQL Connector ODBC Unicode 64-bit driver 8.0.21 to 9.4.0 to resolve security vulnerability reports and they now experience random crashes with Access Violations in myodbc9w.dll.

The SQL is executed via the product InterSystems IRIS which uses the MySQL ODBC driver. We contacted InterSystems support, they analysed the crash dumps, and said the error appears to be an INVALID_POINTER_READ in DescribeCols. I have copied the stack trace below.

We have tried the previous driver version, 9.3.0, and that crashes too eventually. Version 8.0.21 works without any errors.

```

Address 0x00000216`b3be9df0 is where the access violation occurs.

```

 *** Stack trace for last set context - .thread/.cxr resets it

 # Call Site

00 myodbc9w!sqlchar_as_sqlchar(

			struct myodbc::CHARSET_INFO * from_charset = 0x00000000`00000000, 

			struct myodbc::CHARSET_INFO * to_charset = 0x00007ffb`a8f76f50, 

			unsigned char * str = 0x00000216`b2ceaaa0 "???", 

			long * len = 0x00000216`b3be9df0, 

			unsigned int * errors = 0x00000216`af0ca020)+0xa3 [C:\build\sb_1-20060822-1750451268.6343763\mysql-connector-odbc-9.4.0-src\util\stringutil.cc @ 500] 

01 (Inline Function) --------`--------   myodbc9w!_vsscanf_l(

			char * _Format = 0x00000000`00000000 "")+0x20 [C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0\ucrt\stdio.h @ 2153] 

02 myodbc9w!sscanf(

			char * _Buffer = 0x00000216`b2ceaaa0 "???", 

			char * _Format = 0x00000216`b2ceca38 "???")+0x41 [C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0\ucrt\stdio.h @ 2251] 

03 myodbc9w!SQLBrowseConnectW(

			void * hdbc = 0x00007ffb`a8f76f50, 

			wchar_t * in = 0x00000216`b3be9df0 "--- memory read error at address 0x00000216`b3be9df0 ---", 

			short in_len = 0n-24544, 

			wchar_t * out = 0x00000001`af0c0040 "--- memory read error at address 0x00000001`af0c0040 ---", 

			short out_max = 0n-5148, 

			short * out_len = 0x00000000`00000000)+0x15 [C:\build\sb_1-20060822-1750451268.6343763\mysql-connector-odbc-9.4.0-src\driver\unicode.cc @ 1282] 

04 odbc32!SQLColAttributeCover+0x455

05 odbc32!SQLColAttribute+0x204

06 odbcgateway!CStatement::DescribeCols(

			struct zarray * PColInfo = 0x00000216`aedd9a00)+0x32b

07 odbcgateway!DescribeCols(

			struct zarray * hstmt = 0x00000216`aedd99f0, 

			struct zarray * PColInfo = 0x00000216`aedd9a00)+0x202 

08 irisdb!Cdzf(void)+0x2b3d 

```

How to repeat:
We cannot reproduce the error on demand, it seems to crash randomly after an extended period of use. The SQL being executed is standard SELECT statements and looking at an SQL driver log appears to crash after "Using prepared statement;".

InterSystems have analysed full crash dumps and know what is causing the crash. They have asked me to add the following information and evidence. We can provide the full crash dumps if required (very large files). I have changed the severity to S2 as per the definitions - this is causing serious issues for our customers.

- We are experiencing an intermittent access violation in applications using MySQL ODBC Driver 9 (Unicode) on Windows.

Crash dumps show instruction execution occurring inside myodbc9w.dll after the DLL has already been unloaded, consistent with a use-after-unload / stale pointer defect inside the driver.

- The crash is timing-dependent and does not occur on every execution, which is consistent with this class of bug.

Crash Evidence (From Full Memory Dumps):

1. Instruction Pointer Inside an Unloaded Module

From WinDbg analysis:

ExceptionAddress: 00007ffd1336c963 (<Unloaded_myodbc9w.dll>+0x6c963)

ExceptionCode: c0000005 (Access violation)

Attempt to read from address 000002ac2877c808

WinDbg explicitly identifies the faulting instruction as belonging to myodbc9w.dll that has already been unloaded.

2. Module Was Unloaded Before the Crash

Loaded / unloaded module list at time of crash:

Unloaded modules:

00007ffd`13300000 00007ffd`1432b000 myodbc9w.dll

Despite being unloaded, execution later resumes at:

<Unloaded_myodbc9w.dll>+0x6c963

This indicates control flow entered code belonging to the driver after DLL teardown.

3. Access Violation on Heap Address

Attempt to read from address 000002ac2877c808

Address lies in user heap space

Heap extension (!heap -x) cannot resolve it

Consistent with memory whose lifetime has ended

4. Stack Trace Cannot Be Unwound

kpn

# Child-SP RetAddr Call Site

00 000000a9`aa6fec10 00000000`00000000 <Unloaded_myodbc9w.dll>+0x6c963

Return address is NULL

No unwind metadata available

Typical when executing code from an unloaded module