Address sanitizer error in ESQL/C client library when invalid login/pswd
Sebastien Flaesch saw an AddressSanitizer heap-buffer-overflow in the ESQL/C library (_iqset2err) with CSDK 4.50.FC6 against IDS 14.10.FC6 when connecting with an invalid user name; a 16-byte user name reproduced it. He noted it was already reported. David Williams could not reproduce it with CSDK 4.50.FC9W1. It later disappeared after a restart; no fix was confirmed.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello, I have recently faced some strange thing when trying to connect to IDS 14.10.FC6, with CONNECT TO .. USER ... USING, when the user name / password is invalid. I am using CSDK / ESQL Version 4.50.FC6 What makes me wonder is the fact that this occurs only when having a large database created in IDS - after removing the large DB (about 7Gb), problem does no longer occur. You may argue that we should just fix the problem by using a correct user name / password, but this is in the context of a test program that does actually test invalid logins ;-) Here is the Linux / GCC address sanitizer output. I suggest that ESQL/C client lib team checks the related functions... ================================================================= ==2400649==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6030000264c0 at pc 0x7fef834e9541 bp 0x7ffc5e24eaa0 sp 0x7ffc5e24e250 READ of size 33 at 0x6030000264c0 thread T0 #0 0x7fef834e9540 in __interceptor_memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:789 #1 0x7fef7edded90 in _iqset2err (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x32d90) #2 0x7fef7edbe749 in proc_srvrresp (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x12749) #3 0x7fef7edbf725 in asf_connect (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x13725) #4 0x7fef7edbfd06 in sqli_connect_open (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x13d06) #5 0x7fef7faf3158 in ODI_connect /home/sf/genero/devel/fgl/fgl/src/sqldriver/informix/ifx91.ec:597 #6 0x7fef82fa54ac in fglsql_connect ../base/fglsql.c:1562 #7 0x7fef82f93f28 in rts_sql_connect ../base/Sql.c:498 #8 0x7fef82f552e5 in callFu0 /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:318 #9 0x7fef82f5548b in invoke /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:343 #10 0x7fef82f5c1a7 in vm_interprete_impl /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:1048 #11 0x7fef82f2ddf9 in fdb_debug /home/sf/genero/devel/fgl/fgl/src/vm/fdb.c:3253 #12 0x7fef82f510d4 in vm_main /home/sf/genero/devel/fgl/fgl/src/vm/vm.c:931 #13 0x56417a00c1bb in main /home/sf/genero/devel/fgl/fgl/src/vm/fglrun.c:5 #14 0x7fef82cb1d09 in __libc_start_main ../csu/libc-start.c:308 #15 0x56417a00c0c9 in _start (/home/sf/genero/devel/fgl/fgl/opt/fgl/bin/fglrun+0x10c9) 0x6030000264c0 is located 0 bytes to the right of 32-byte region [0x6030000264a0,0x6030000264c0) allocated by thread T0 here: #0 0x7fef8355a037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7fef7e6dc439 in meAlloc (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifos.so+0x13439) #2 0x7fef7eb751f1 in ascOptBin (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x281f1) #3 0x7fef7eb6f21a in ascBinary (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x2221a) #4 0x7fef7eb70b95 in pfConReq (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x23b95) #5 0x7fef7eb6a647 in cmReqSync (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x1d647) #6 0x7fef7eb6b0e8 in cmConReq (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x1e0e8) #7 0x7fef7eb60107 in ascRequest (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x13107) #8 0x7fef7eb626c5 in ASF_Call (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/libifasf.so+0x156c5) #9 0x7fef7edbf707 in asf_connect (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x13707) #10 0x7fef7edbfd06 in sqli_connect_open (/opt3/dbs/ifx/CSDK-4.50.FC5/lib/esql/libifsql.so+0x13d06) #11 0x7fef7faf3158 in ODI_connect /home/sf/genero/devel/fgl/fgl/src/sqldriver/informix/ifx91.ec:597 #12 0x7fef82fa54ac in fglsql_connect ../base/fglsql.c:1562 #13 0x7fef82f93f28 in rts_sql_connect ../base/Sql.c:498 #14 0x7fef82f552e5 in callFu0 /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:318 #15 0x7fef82f5548b in invoke /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:343 #16 0x7fef82f5c1a7 in vm_interprete_impl /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:1048 #17 0x7fef82f2ddf9 in fdb_debug /home/sf/genero/devel/fgl/fgl/src/vm/fdb.c:3253 #18 0x7fef82f510d4 in vm_main /home/sf/genero/devel/fgl/fgl/src/vm/vm.c:931 #19 0x56417a00c1bb in main /home/sf/genero/devel/fgl/fgl/src/vm/fglrun.c:5 #20 0x7fef82cb1d09 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:789 in __interceptor_memmove Shadow bytes around the buggy address: 0x0c067fffcc40: fd fd fd fa fa fa fd fd fd fd fa fa fd fd fd fd 0x0c067fffcc50: fa fa 00 00 01 fa fa fa fd fd fd fa fa fa fd fd 0x0c067fffcc60: fd fa fa fa fd fd fd fa fa fa 00 00 05 fa fa fa 0x0c067fffcc70: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa 0x0c067fffcc80: fa fa 00 00 00 00 fa fa 00 00 00 fa fa fa fd fd =>0x0c067fffcc90: fd fd fa fa 00 00 00 00[fa]fa 00 00 00 04 fa fa 0x0c067fffcca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffccb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffccc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffccd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffcce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==2400649==ABORTING ------------------------------ Sebastien FLAESCH ------------------------------
I have reinstalled my IDS server and now the problem occurs again... I could reproduce with a simple ESQL/C program. When the invalid user name has 16 bytes, I get the address sanitizer error. Any clue? Informix bug? Seb To reproduce: sf@toro:~/dbvendors/informix/problems$ echo $LC_ALL en_US.utf8 sf@toro:~/dbvendors/informix/problems$ echo $CLIENT_LOCALE en_us.utf8 sf@toro:~/dbvendors/informix/problems$ echo $DB_LOCALE en_us.utf8 sf@toro:~/dbvendors/informix/problems$ export INFORMIXC="gcc -g -fsanitize=address" sf@toro:~/dbvendors/informix/problems$ esql -o test008.bin test008.ec sf@toro:~/dbvendors/informix/problems$ ./test008.bin ------------------------------ Sebastien FLAESCH ------------------------------
Already reported: https://community.ibm.com/community/user/datamanagement/communities/community-home/digestviewer/viewthread?MessageKey=17225b45-64be-405b-ada3-a9c5b52b542f&CommunityKey=cf5a1f39-c21f-4bc4-9ec2-7ca108f0a365&tab=digestviewer&SuccessMsg=Thank%20you%20for%20submitting%20your%20message ------------------------------ Sebastien FLAESCH ------------------------------
HI, Try with a later Clientk SDK Does not reproduce on RHEL 8 Developer Red Hat Enterprise Linux release 8.7 (Ootpa) Client SDK 4.50.FC9W1 with gcc 8.5.0 gcc 12.2.0 gcc 13.0.1 20230226 (experimental) (git clone of repo!) Regards, David. ------------------------------ David Williams ------------------------------
Hi David and thanks for the suggestion. I will for sure install the latest CSDK, but the fact that you don't repro does not mean that the problem is fixed. After restarting my OS (and restarting IDS of course) the problem disappeared... Ideally, I would expect CSDK dev team to confirm that this bug has been identified and fixed. I can't see any bug list / fix in https://www.ibm.com/docs/en/informix-servers/14.10?topic=information-client-sdk Seb ------------------------------ Sebastien FLAESCH ------------------------------