>>> I like this idea. As PODOFO_MULTI_THREAD will enable C++11 >>Is there a chance we might get there? Who would be able to make that decision? >consider the decision being made. Again, from my point of view. In >other words, feel free to provide a patch with the suggested changes.
Ok, I can submit a patch which uses C++11 thread_local when PODOFO_MULTI_THREAD is defined. The recursion guard definition will look like this: #if defined(PODOFO_MULTI_THREAD) static int thread_local s_nRecursionDepth; // PoDoFo with threading support requires C++11 compiler with thread_local #else static int s_nRecursionDepth; // PoDoFo is single threaded #endif Does that work for everyone? > Not when the user of podofo already used some 64 KB before calling podofo. To > me it seems more reasonable to use a more conservative value which would not > consume more than some half (or tenth?) of the available stack in the worst > case. I’ll also reduce the 500 max recursion depth as suggested (probably to 256) And I’ll also include the new parser unit tests which test for deep recursion and reference loops We’re also testing a patch for CVE-2018-20797. This is caused by an invalid negative value for one of the FlateDecode compression parameters which results in a call to podofo_calloc( -14 ) == podofo_calloc( 0xfffffffffffffff2 ) Best Regards Mark Mark Rogers - mark.rog...@powermapper.com PowerMapper Software Ltd - www.powermapper.com Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL From: Christopher Creutzig <ccreu...@mathworks.com> Date: Thursday, 25 November 2021 at 07:16 To: Michal Sudolsky <sudols...@gmail.com> Cc: "PowerMapper.com" <mark.rog...@powermapper.com>, "podofo-users@lists.sourceforge.net" <podofo-users@lists.sourceforge.net> Subject: RE: [Podofo-users] PoDoFo and recursive stack consumption CVEs >> If we want to avoid UB in the multithreaded world, I’m afraid we will have >> to make a C++11 compiler a requirement, as C++03 never acknowledged the >> existence of threads. (That is not limited to this place, a lot of methods >> like PdfEncodingFactory::GlobalPdfRomanEncodingInstance are not currently >> threadsafe in C++03, as discussed earlier.) > That is not thread-safe even in C++11. True, but C++11 or later would give us the tools to make it thread-safe. > Except that some things are not so available as threads like for example > thread_local and atomic operations. thread_local equivalents are available for g++, clang, and MSVC. That covers the compilers listed in https://github.com/NickNaso/PoDoFo/blob/master/README.md#installation_with_cmake. See my proposed PODOFO_THREAD_LOCAL in https://sourceforge.net/p/podofo/mailman/message/37389082/. > I like this idea. As PODOFO_MULTI_THREAD will enable C++11 Is there a chance we might get there? Who would be able to make that decision? Cheers, Christopher The MathWorks GmbH | Friedlandstr.18 | 52064 Aachen | District Court Aachen | HRB 8082 | Managing Directors: Bertrand Dissler, Steven D. Barbo, Jeanne O’Keefe
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
