This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/14547] strcoll integer / buffer overflow
- From: "siddhesh at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 25 Oct 2013 13:30:01 +0000
- Subject: [Bug libc/14547] strcoll integer / buffer overflow
- Auto-submitted: auto-generated
- References: <bug-14547-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14547
--- Comment #10 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
(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 are receiving this mail because:
You are on the CC list for the bug.