(In reply to mancha from comment #8) > Hello. I applied Siddhesh's three patches (2 CVE fixes + strcoll > refactoring) and the PoCs no longer trigger overflows. > > What is a reasonable runtime to expect on those PoCs post-patch?
It should finish a few minutes before forever :) The *_nocache code is O(n^3) (IIRC), so it's very very slow. If it has to crash due to a buffer or stack overflow, it ought to be gone in a few minutes based on some arbitrary tests I did by introducing buffer overflows and accesses beyond bounds in the code. I've added an xtest (i.e. an optional test, which you can run using `make xcheck`) that does exactly this - run the reproducer and signal a success if the program doesn't crash in about five minutes. If you want to do a correctness test then I'd suggest commenting out the get_next_seq_cached paths so that get_next_seq_nocache is called all the time and then run your usual strcoll correctness tests. Maybe we could add some internal test hooks that allow us to do this seamlessly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048203 Title: (CVE-2012-4412) glibc: strcoll() integer overflow leading to buffer overflow To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/1048203/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
