You should continue to report bugs to the JIRA bug tracker. I have been doing significant evaluation of heap versus stack bugs. There appears to be no standard solution to accommodate the true process/thread stack address issues since the underlying system architectures have no good way to dynamically reallocate operational thread stack assignment space. Stack overflow in a thread causes a segmentation fault that aborts the entire process.
As a senior application and systems architect, I normally create a monitoring process that allows child processes to die and provide features to allow critical systems to continue running when the child processes fault and abort. The Xalan ans Xerces libraries are built on pure C/C++ architectures without an overarching systems monitoring process. Memory allocation for stack and heap is an application design requirement because the C/C++ libraries are not built on a platform advanced dynamic memory allocation fundamentals. The Xalan and Xerces libraries allow for Out-of-Memory heap allocation to be trapped and handled as exceptions. Process/Thread stack overflow always creates a segmentation fault because stack allocation is static and cannot be dynamically expanded by most operating systems. If you find a good way to handle and recover from otherwise fatal memory address segmentation faults, tell the world, patent the issue, or go to work and get money from your design. Memory buffer overflows are well understood and can be provided good protection. Heap managers usually throw an out-of-memory exception. Stack overflow usually results in a fatal segmentation fault. Sincerely, Steven J. Hathaway > On Thu, May 4, 2017 at 9:43 AM, Nicolas Grégoire > <nicolas.grego...@agarri.fr >> wrote: > >> Hello, >> >> I recently identified several vulnerabilities affecting Xalan-C v1.11. >> While researching them, I noticed that a few of them are already listed >> in the public bug tracker. >> >> As an example, ticket XALANC-762 (created on 03/Apr/15) refers to a >> stack-based buffer overflow during conversion of large numbers: >> https://issues.apache.org/jira/browse/XALANC-762 >> >> Should I report the other bugs I found in the bug tracker (or somewhere >> else like a private mailing list)? Is there still any active >> development of this code base? >> > > I've not see much activity on Xalan-C. Recording bugs you find is always > nice but I am not sure you'll see any fixes. Hopefully someone else will > pipe in. > > Gary > > >> Regards, >> Nicolas Grégoire >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org >> For additional commands, e-mail: dev-h...@xalan.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > Stack and Heap Overflow Analysis! There appears to be no standard way to implement stack overflow protection. Most always, the stack overflow manifests itself as a segmentation fault that causes the entire process to abort. The architecture used in C++ for Xalan and Xerces libraries do not use a garbage collected memory management system and are therefore unable to dynamically increase the size of stack space allocated to threads and processes. Java systems may implement dynamic memory management in a pure java runtime environment, but not if JNI is used. Microsoft C# uses dynamic memory implementing their proprietary .NET framework environment. Native C/C++ requires that the application perform its own memory managemment and does not benefit from the .NET framework garbage collection, intelligent pointer movement, heap memory compression, and stack reallocation. C/C++ systems are directly bound to the virtual address space allocated to a process and its threads. Allocation of stack space for threads is assigned at thread creation time. There is no standard way to proactively determine how much stack space is available for pushing content onto the stack such as subroutine and system calls to methods and functions. The C++/STL containers have some semblance of stack architectures, but they are dynamically implemented in the heap as allocated objects. The amount of heap space in process virtual memory is also finite, but is independent of the thread and process stack space. Is the stack space vulnerability the process/thread stack space, or is it the available heap memory consumed by C++/STL containers? When you exhaust the stack, the most often result is a segmentation fault. When you exhaust the heap space, an out-of-memory exception can generally be processed for graceful recovery within the program. A true process/thread stack overflow is fatal to the process. A heap allocation (out-of-memory) does have a chance of graceful recovery and error reporting. An infinite recursive stylesheet creates a known abortive condition of infinite memory consumption. It is encumbant of the application designer to handle recursion limits. The library designer has no knowledge of all application recursion template needs and therefore cannot and should not arbitrarily enforce a maximum recursion depth. Such fixes can be handled by the application designer. Sincerely, Steven J. Hathaway
