[Bug 813340] New: Suspected memory corruption in standard capi20 lib
https://bugzilla.novell.com/show_bug.cgi?id=813340 https://bugzilla.novell.com/show_bug.cgi?id=813340#c0 Summary: Suspected memory corruption in standard capi20 lib Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 0 Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jan.fengler@adviqo.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31 The capi20 lib from the i4l-base source-package from http://download.opensuse.org/repositories/home:/kkeil:/ISDN/openSUSE_Factory... (and also Version 3.23-100.1 which is newer) seems to create memory corruption during capi20_put_message sending data_b3_req, because no memory is assigned for the data that is put behind the original message in the function capi_processMessage (capi20.c row 962ff). Unfortunately this seems to be a private function and so i could not easily write a test against the entire lib. Reproducible: Always Steps to Reproduce: I provide an example program that uses a 1:1 copy of the original function. I use capi via JNI from Java and it crashes when freeing memory exactly as the test program does. Actual Results: Memory corruption when freeing the memory used for the data_b3_req-message. Expected Results: No memory corruption, the program should terminate without a problem. The last known working version (from openSuSE 10.3) assigned memory for SND_BUFSIZ bytes and copied the original message to this before copying the data bytes after the message and that worked. I will change the code of the function standardPutMessage to do this to avoid the problem and add a patch to this bug report if it works with the patch. I must admit that i could have overseen something, but unfortunately it seems not so far. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c1
--- Comment #1 from Jan Fengler
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c2
--- Comment #2 from Jan Fengler
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c
Jan Fengler
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c3
--- Comment #3 from Jan Fengler
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c
Xiaolong Li
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c
Christian Boltz
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c4
Karsten Keil
https://bugzilla.novell.com/show_bug.cgi?id=813340
https://bugzilla.novell.com/show_bug.cgi?id=813340#c5
--- Comment #5 from Jan Fengler
Thnak you for debugging this, I 'll have a look later this week.
I think 3.25 is no longer affected, because the old way with a maximized sendbuffer is implemented again. Using that or the patched older Version results in an assertion error after some time stopping everything ("assert(buf->used == 1)"). Investigating this i found that in the method "capi_processMessage" a call to "capi_return_buffer" resulted in the assertion error, because cleanup_buffers_for_plci already called capi_return_buffer and if that is called again, buf->used is no longer 1. The working Version from openSuSE 10.3 (2007.9.17-5.x64) has nearly the same code and i was not able to find the reason why the behavior is different between the two versions (the older one is working and we use direct calls to capi20.h-Methods). A possible workaround is to check if the buffer is marked as used, before passing it to "capi_return_buffer" like this (from my development version, therefore the debug output: .. } else if ( nSubCommand == CAPI_RESP ) { CapiDebug(1, "capi_processMessage\n"); struct recvbuffer *buf = applinfo[nApplId]->buffers+CAPIMSG_U16( pnMsg, 12 ); if (buf->used) { CapiDebug(1, "capi_processMessage - return_buffer_used\n"); capimsg_setu16( pnMsg, 12, capi_return_buffer( nApplId, CAPIMSG_U16( pnMsg, 12 ) ) ); } else { CapiDebug(1, "capi_processMessage - return_buffer_used skipped!\n"); capimsg_setu16( pnMsg, 12, buf->datahandle); } } .. but to me this seems only as a workaround that handles the symptoms, not the source of the problem, though this workaround avoids triggering the assertion. Does anybody have an idea, where the different behavior is resulting from? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=813340
http://bugzilla.novell.com/show_bug.cgi?id=813340#c8
--- Comment #8 from Karsten Keil
participants (1)
-
bugzilla_noreply@novell.com