Buffer passed to SQLSetConnectAttrW used after function return

[bkline]

Background

According to the ODBC specification and Microsoft's online documentation:

All buffers are allocated and freed by the application. If a buffer is not deferred, it need only exist for the duration of the call to a function.

SQLSetConnectAttrW is not one of the functions included in the table of functions which are allowed to use deferred buffers.

Expected

The implementation of SQLSetConnectAttrW creates its own copy of non-scalar values it will need to use after the function has returned, and the application can free the buffers for those values as soon as SQLSetConnectAttrW has returned.

Observed

An application using Microsoft's ODBC Driver 18 for SQL Server can crash unless it extends the lifetime of any buffers passed to SQLSetConnectAttrW until after the later call to SQLDriverConnectW has returned.

Repro

The script which can be used to reproduce this behavior is contained in the SQLAlchemy issue in which the problem was first reported.

Important

In order to bypass workarounds implemented to avoid this bug, it is necessary to test with a version of SQLAlchemy earlier than 2.0.48 and a version of pyodbc no later than 5.3.0.

Environment

Component	Version
OS	Linux x86_64
pyodbc	5.3.0
SQLAlchemy	2.0.47
azure-core	1.39.0
azure-identity	1.25.3
Driver	msodbcsql18 18.6.1.1-1

[bkline]

The failure output reported for the SQLAlchemy ticket indicates that the C stack was unavailable on the system being used, so I am including the stack dump from my own system to show more specifically where the crash occurs. Again, if the script is run using a patched version of pyodbc which keeps the buffers for the values passed earlier to SQLSetConnectAttrW alive until SQLDriverConnectW has returned, the crash never occurs.

(gdb) bt
#0  __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:831
#1  0x00007ffff45072c0 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#2  0x00007ffff450f49e in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#3  0x00007ffff45386d7 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#4  0x00007ffff45387d7 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#5  0x00007ffff452c7a3 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#6  0x00007ffff452cfc1 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#7  0x00007ffff452ff72 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#8  0x00007ffff45308f3 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#9  0x00007ffff449c163 in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#10 0x00007ffff44d22be in ?? () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#11 0x00007ffff44a0079 in SQLDriverConnectW () from /opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.6.so.1.1
#12 0x00007ffff75896d7 in SQLDriverConnectW (hdbc=0x7fffb8000ba0, hwnd=0x0, conn_str_in=0x7ffff489f2b0,
    len_conn_str_in=-3, conn_str_out=0x0, conn_str_out_max=0, ptr_conn_str_out=0x0, driver_completion=0)
    at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLDriverConnectW.c:777
#13 0x00007ffff75e1b2d in Connect (encoding=0x0, timeout=0, hdbc=0x7fffb8000ba0, pConnectString=0x7ffff4922090)
    at src/textenc.h:121
#14 Connection_New (pConnectString=pConnectString@entry=0x7ffff4922090, fAutoCommit=fAutoCommit@entry=false,
    timeout=timeout@entry=0, fReadOnly=fReadOnly@entry=false, attrs_before=attrs_before@entry=0x7ffff481a080,
    encoding=encoding@entry=0x0) at src/connection.cpp:216
#15 0x00007ffff75ecbb1 in mod_connect (self=<optimized out>, args=<optimized out>, kwargs=<optimized out>)
    at src/pyodbcmodule.cpp:523
#16 0x0000000000581e9f in cfunction_call (func=0x7ffff76ea8e0, args=<optimized out>, kwargs=<optimized out>)
    at ../Objects/methodobject.c:537
#17 0x000000000054b11c in PyObject_Call () at ../Objects/call.c:376
#18 0x00000000005db0ba in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>,
    throwflag=<optimized out>) at Python/bytecodes.c:3254
#19 0x000000000054cb74 in _PyObject_VectorcallTstate (kwnames=0x7ffff465c850, nargsf=<optimized out>,
    args=0x7ffff475fe90, callable=0x7ffff4fdaca0, tstate=0x1b33610) at ../Include/internal/pycore_call.h:92
#20 method_vectorcall (method=<optimized out>, args=0x7ffff475fe98, nargsf=<optimized out>, kwnames=0x7ffff465c850)
    at ../Objects/classobject.c:61
#21 0x000000000054b199 in PyObject_Call () at ../Objects/call.c:376
#22 0x00000000005db0ba in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>,
    throwflag=<optimized out>) at Python/bytecodes.c:3254
#23 0x000000000054a7c2 in _PyFunction_Vectorcall (kwnames=0x0, nargsf=<optimized out>, stack=0x7fffd27fb7f0,
    func=0x7ffff559af20) at ../Objects/call.c:419
#24 _PyObject_FastCallDictTstate (kwargs=0x0, nargsf=<optimized out>, args=0x7fffd27fb7f0,
    callable=0x7ffff559af20, tstate=0x1b33610) at ../Objects/call.c:133
#25 _PyObject_Call_Prepend (tstate=tstate@entry=0x1b33610, callable=callable@entry=0x7ffff559af20,
    obj=obj@entry=0x7ffff46444d0, args=args@entry=0x7ffff467c4f0, kwargs=<optimized out>) at ../Objects/call.c:508
#26 0x000000000059dddf in slot_tp_init (self=0x7ffff46444d0, args=0x7ffff467c4f0, kwds=<optimized out>)
    at ../Objects/typeobject.c:9014
--Type <RET> for more, q to quit, c to continue without paging--c
#27 0x00000000005998a3 in type_call (type=<optimized out>, type@entry=0x12631d0, args=args@entry=0x7ffff467c4f0,
    kwds=kwds@entry=0x0) at ../Objects/typeobject.c:1673
#28 0x0000000000548f75 in _PyObject_MakeTpCall (tstate=0x1b33610, callable=0x12631d0, args=<optimized out>,
    nargs=1, keywords=0x0) at ../Objects/call.c:240
#29 0x00000000005499ad in _PyObject_VectorcallTstate (kwnames=<optimized out>, nargsf=<optimized out>,
    args=<optimized out>, callable=<optimized out>, tstate=<optimized out>) at ../Include/internal/pycore_call.h:90
#30 0x00000000005d6f09 in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>,
    throwflag=<optimized out>) at Python/bytecodes.c:2706
#31 0x000000000054a7c2 in _PyFunction_Vectorcall (kwnames=0x0, nargsf=<optimized out>, stack=0x7fffd27fbb10,
    func=0x7ffff55b25c0) at ../Objects/call.c:419
#32 _PyObject_FastCallDictTstate (kwargs=0x0, nargsf=<optimized out>, args=0x7fffd27fbb10,
    callable=0x7ffff55b25c0, tstate=0x1b33610) at ../Objects/call.c:133
#33 _PyObject_Call_Prepend (tstate=tstate@entry=0x1b33610, callable=callable@entry=0x7ffff55b25c0,
    obj=obj@entry=0x7ffff467da30, args=args@entry=0x7ffff482f520, kwargs=<optimized out>) at ../Objects/call.c:508
#34 0x000000000059dddf in slot_tp_init (self=0x7ffff467da30, args=0x7ffff482f520, kwds=<optimized out>)
    at ../Objects/typeobject.c:9014
#35 0x00000000005998a3 in type_call (type=<optimized out>, type@entry=0x125a760, args=args@entry=0x7ffff482f520,
    kwds=kwds@entry=0x0) at ../Objects/typeobject.c:1673
#36 0x0000000000548f75 in _PyObject_MakeTpCall (tstate=0x1b33610, callable=0x125a760, args=<optimized out>,
    nargs=1, keywords=0x0) at ../Objects/call.c:240
#37 0x00000000005499ad in _PyObject_VectorcallTstate (kwnames=<optimized out>, nargsf=<optimized out>,
    args=<optimized out>, callable=<optimized out>, tstate=<optimized out>) at ../Include/internal/pycore_call.h:90
#38 0x00000000005d6f09 in _PyEval_EvalFrameDefault (tstate=<optimized out>, frame=<optimized out>,
    throwflag=<optimized out>) at Python/bytecodes.c:2706
#39 0x000000000054cb12 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=1, args=0x7fffd27fbe18,
    callable=0x7ffff766d300, tstate=0x1b33610) at ../Include/internal/pycore_call.h:92
#40 method_vectorcall (method=<optimized out>, args=0xb47dc0 <_PyRuntime+76288>, nargsf=<optimized out>,
    kwnames=0x0) at ../Objects/classobject.c:69
#41 0x00000000006f80ec in thread_run (boot_raw=0x1b335e0) at ../Modules/_threadmodule.c:1114
#42 0x00000000006b8fec in pythread_wrapper (arg=<optimized out>) at ../Python/thread_pthread.h:237
#43 0x00007ffff7c9caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#44 0x00007ffff7d29c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Here is the tail end of the logging for the happy path (pyodbc patched to work around the bug):

2026-03-30 11:30:41,234 [MainThread] ---
2026-03-30 11:30:41,234 [MainThread] Done: 8000/8000 in 413.6s (97 refreshes)
2026-03-30 11:30:41,235 [MainThread] No crashes.

So 8,000 successful connections, no crashes.

One other thing I'll note is that I found the SQLAlchemy repro script's "warmup" connection at the start to be overly optimistic about how long it takes for a dormant Azure database to wake up. I created a little script to connect once and ran it a few times until it was able to connect successfully. Without that preparation, the repro script would fail for a reason unrelated to the bug being reproduced.

[jahnvi480]

Hi @bkline, thanks for the detailed report and the stack trace, really helpful.

We took a close look at this on our end. In the PHP drivers, the buffers we pass to SQLSetConnectAttr for non-scalar connection attributes are kept alive for the entire duration of the connection attempt, so we're not directly affected by this.

We're going to reach out to the ODBC driver team internally to make sure they're aware of this and can address it. Unfortunately, they don't have an external issue tracker, so we won't be able to share a link to a tracking issue on their side, but we'll make sure this gets in front of them.

Appreciate you taking the time to investigate and document this so thoroughly.