From francis.brosnan at aspl.es Wed Oct 19 17:22:17 2016 From: francis.brosnan at aspl.es (Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?=) Date: Wed, 19 Oct 2016 17:22:17 +0200 Subject: [Vortex] [ANN] Vortex Library 1.1.18 is ready for download! Message-ID: <1476890537.4417.37.camel@aspl.es> ################################################### ## Vortex Library 1.1.18 ## ## "Sharknado attack" ## ################################################### Release note ~~~~~~~~~~~~ Advanced Software Production Line is proud to announce Vortex Library 1.1.18 "Sharknado" release availability: an open source "BEEP Core" protocol implementation written in C, mapped onto TCP/IP. Vortex Library is a stable and robust application protocol development toolkit, with active support for Microsoft Windows and GNU/Linux platforms. Check out the following links to get ready with Vortex Library: - http://www.aspl.es/vortex [Vortex Library homepage] - http://www.aspl.es/vortex/downloads [Vortex Library downloads, binaries w64 & w32] - http://www.core-admin.com [Featured product: Core-Admin] This release in short ~~~~~~~~~~~~~~~~~~~~~ - Several PyVortex improvements to increase thread granularity and reentrant code. - Improved log reporting on connection lost/broken to include more information about remote peer, serverName... Change notifications ~~~~~~~~~~~~~~~~~~~~ None Changes since 1.1.17 ~~~~~~~~~~~~~~~~~~~~ * [fix] Updated vortex_connection and vortex_frame_factory module to report remote ip when a failure is found for connection lost or connection close detected.. * [fix] Added more information to error log generated when connection error is found (serverName, status and message) * [fix] Added additional pairs of Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS to py vortex channel module to make send operations allow others python threads (fixes dead lock reported) * [fix] Updated py-vortex-ctx to allow python threading code before calling vortex_exit_ctx (Py_BEGIN_ALLOW_THREADS)... * [fix] Updated py_vortex_connection_dealloc to allow python threads (Py_BEGIN_ALLOW_THREADS) before calling vortex API (vortex_connection_is_ok, vortex_connection_shutdown, vortex_connection_ref_count, etc.., inside py_vortex_connection_dealloc * [fix] Added more declarations for allow/end threads inside py_vortex_ctx_bridge_event when removing event after finishing event installed through vortex.Ctx ().new_event * [fix] Several updates to make vortex.Ctx () internal call to vortex_ctx_free to allow/end threads around that call * [fix] Making vortex_connection_ref_count to avoid acquiring mutex (ref_mutex) to report current data. * [fix] Making vortex_ctx_ref_count to report reference counting without locking internal ref_mutex * [fix] Updated VortexLogHandlerFull implementation to pass as first parameter a reference to the VortexCtx context.. * [fix] Fixed critical section to acquire GIL just after removing bridged event.. * [fix] Updated CLOSE_HANDLE (py_vortex_ctx_record_close_handler) to release GIL while searching for watcher handler and removing it after finishing recording.... About Us ~~~~~~~~ Advanced Software Production Line provides GNU/Linux support and consulting services to help organisations to introduce GNU/Linux inside its process. Contact us, using English or Spanish, to get commercial support and/or BEEP based development services. You can reach us: http://www.aspl.es - info at aspl.es Enjoy Vortex Library! -- Francis Brosnan Bl?zquez - francis at aspl.es Advanced Software Production Line - http://www.aspl.es 19th Oct 2016, Madrid (Spain) From ddrusowitsch at barracuda.com Wed Oct 19 17:25:20 2016 From: ddrusowitsch at barracuda.com (David Drusowitsch) Date: Wed, 19 Oct 2016 17:25:20 +0200 Subject: [Vortex] Possible race condition between reader worker thread and TLS negotiation Message-ID: <58079060.6020004@barracuda.com> Hi Vortex Team, we are currently using a relatively old vortex version 1.0.5.b2830.g2831 in our applications/services. A few weeks ago we got a bug report, one of our services was acting weird, it got dis-functional or even worse it segfaults over the day. After a lot of investigation work, we were able to reproduce it. Most of the time it happens in the in the region of vortex reader. The reader struggles after trying to dispatch a previously freed connection. Classic invalid memory access. Our service uses multiple threads to establish secure TLS connections. Due to stability and other paranoid reasons, this is done before every data transmission. The more threads are doing communication work, the bigger the possibility to crash. So this is my explanation: The connection gets renewed during TLS negotiation. A new "object" would be allocated and the other one get marked as not connected and waiting for destruction (unref). If I understood the process of the reader correctly, a new connection gets add to the watching queue and epoll is waiting till new data is available on a socket. If the connection "object" exchange exactly happens during the run of the reader worker thread, it could happen that it frees the "object" to soon, resulting in strange behaviours I mentioned before. Seems the watching of the former connection was not already finished and needs at least one run through of __vortex_reader_run. The object got freed during __vortex_reader_build_set_to_watch but it's reference still remaining as an reference entry in the private area on epoll. What would lead to an invalid memory access during vortex_io_waiting_invoke_dispatch in further consequence. Attached you'll find a short patch, where we moved the finally destruction of the connection towards the place dispatching finished. This fixed out issues. Would be possible that this issue is also present in the last release of version 1.0 (I think 1.0.17), would be cool if you could check on this. Best Regards, David -- David Drusowitsch Software Engineer Lassallestrasse 7A / Unit 4 / 2 ? 1020 Vienna ? Austria o: +43 508-100 | ddrusowitsch at barracuda.com Connect with us: barracuda.com/connect [cid:part2.03000505.09030708 at barracuda.com] ________________________________ Barracuda Networks AG Vorsitzender des Aufsichtsrates/ Chairman of the supervisory board: Dr. Klaus Perktold Vorstand/ Executive Board: Dr. Wieland Alge, Mag. Guenter Klausner Sitz der Gesellschaft/ Registered office: 6020 Innsbruck, Austria Handelsgericht Innsbruck Firmenbuch/ Registration Number: 184392s UID-Nr/ VAT Number: ATU47509003 Zweigniederlassung Deutschland/ Office Germany: Radlkoferstr. 2, 81373 M?nchen Handelsregister M?nchen / Registration Number: HRB 171749 UID-Nr/ VAT Number: DE237607533 =========================================================== Considering Office 365? Barracuda security and storage solutions can help. Learn more about Barracuda solutions for Office 365 at http://barracuda.com/office365. DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. =========================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dcjgbjfi.gif Type: image/gif Size: 6743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vortex-phion-invalid-mem-access-fix.patch Type: text/x-patch Size: 3433 bytes Desc: not available URL: