Bug #100329 ODBC Driver overwriting memory causes process dead when parameterized query on
Submitted: 27 Jul 2020 6:25 Modified: 4 Aug 2020 2:06
Reporter: Vera Li Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S2 (Serious)
Version:8.0.21 OS:Microsoft Windows
Assigned to: Bogdan Degtyariov CPU Architecture:Any

[27 Jul 2020 6:25] Vera Li 
Description:
We are using parameterized queries against MySQL ODBC driver on Windows and found some SQL query will overwrite the memory and cause our process dead. My driver version is 8.0.21.

My SQL query looks like:

select    distinct `pa11`.`CUSTOMER_ID`  `CUSTOMER_ID`,
    CONCAT(`a12`.`CUST_LAST_NAME`, `a12`.`CUST_FIRST_NAME`)  `CustCol_12`,
    CONCAT((Case when `pa11`.`WJXBFS1` = ? then ? else ? end), `pa11`.`WJXBFS1`)  `WJXBFS1`
from    (select    `a11`.`CUSTOMER_ID`  `CUSTOMER_ID`,
        max(CONCAT(`a11`.`CUST_LAST_NAME`, `a11`.`CUST_FIRST_NAME`))  `WJXBFS1`
    from    `lu_customer`    `a11`
    group by    `a11`.`CUSTOMER_ID`
    )    `pa11`
    join    `lu_customer`    `a12`
      on     (`pa11`.`CUSTOMER_ID` = `a12`.`CUSTOMER_ID`)
with parameters:
    丁勤毅
    真
    假

And I tried with an older driver version 8.0.12. Memory corruption doesn't happen but it can not get entries unless I execute the query more than one time. The first time I executed the query it returned 0 rows.

How to repeat:
Run below SQL query against MySQL ODBC Driver(8.0.21):

select    distinct `pa11`.`CUSTOMER_ID`  `CUSTOMER_ID`,
    CONCAT(`a12`.`CUST_LAST_NAME`, `a12`.`CUST_FIRST_NAME`)  `CustCol_12`,
    CONCAT((Case when `pa11`.`WJXBFS1` = ? then ? else ? end), `pa11`.`WJXBFS1`)  `WJXBFS1`
from    (select    `a11`.`CUSTOMER_ID`  `CUSTOMER_ID`,
        max(CONCAT(`a11`.`CUST_LAST_NAME`, `a11`.`CUST_FIRST_NAME`))  `WJXBFS1`
    from    `lu_customer`    `a11`
    group by    `a11`.`CUSTOMER_ID`
    )    `pa11`
    join    `lu_customer`    `a12`
      on     (`pa11`.`CUSTOMER_ID` = `a12`.`CUSTOMER_ID`)
with parameters:
    丁勤毅
    真
    假
[27 Jul 2020 20:32] MySQL Verification Team 
Thank you for the bug report. Are able to provide the C file to test it?. Thanks.
[28 Jul 2020 2:26] Vera Li 
Could you suggest what is C file?
[28 Jul 2020 2:42] Bogdan Degtyariov 
Hi Vera,

In order to diagnose and resolve this issue faster we need a C or a C++ code that helps to reproduce the issue on our side.

It can also be a VB code or any other fragment of source that shows what exactly is done to create the memory corruption.

Another piece of diagnostic information that can greatly help us is the ODBC Driver Trace, which can be enabled through the ODBC Administrator in Windows.
You need to go to the Tracing tab and specify the path for the log file. Please note that sometimes it requires checking "Machine-Wide tracing" option.

Tracing should be activated before running your program and stopped after you had the memory corruption problem. Tracing can cause significant slow-down and has to be deactivated as soon as it is not needed.
Thanks.
[28 Jul 2020 2:50] Bogdan Degtyariov 
C is a high-level programming language that can be compiled to native processor instructions. Having a test case written in C is the optimal case for us because in most situations it points directly to the function where the problem occurs.
[28 Jul 2020 7:04] Vera Li 
use pyodbc to reproduce the issue

Attachment: test_pyodbc.py (text/plain), 1.34 KiB.
[28 Jul 2020 7:19] Vera Li 
Hi Bogdan, Thanks for your reply. I had a python script to reproduce the issue and attached it. Hope it could help.
The SQL trace would be really large and exceed the limit of attachment. So it's not attached.
[28 Jul 2020 7:37] Bogdan Degtyariov 
Thank you Vera,

Perhaps you could compress the trace uzing ZIP or 7Z?
The text data like in the trace can be compressed really well.
[28 Jul 2020 9:32] Vera Li 
SQL Trace

Attachment: SQLTrace-1.7z (application/octet-stream, text), 269.05 KiB.
[28 Jul 2020 9:33] Vera Li 
Hi Bogdan, sql trace is attached
[28 Jul 2020 9:45] Bogdan Degtyariov 
Hi Vera,

Thank you for providing all the information we requested.
I was able to repeat the issue.
It looks like python dies silently during fetching records and does not produce any output.

The bug status is now changed to verified.
We will keep you informed on the progress of fixing it.
[29 Jul 2020 2:45] Vera Li 
Thank you Bogdan! Looking forward to the fix.
[3 Aug 2020 9:57] Bogdan Degtyariov 
Posted by developer:
 
The bug is fixed and the fix is pushed into the source tree.
[3 Aug 2020 19:55] Philip Olson 
Posted by developer:
 
Fixed as of the upcoming MySQL Connector/ODBC 8.0.22 release, and here's the proposed changelog entry from the documentation team:

Fixed an issue where a parameterized query could cause memory corruption.

Thank you for the bug report.
[4 Aug 2020 2:06] Vera Li 
Glad to hear that! Thanks!