This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/14547] strcoll integer / buffer overflow


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]